rloew

A bootable CD requires a boot image separate from the ISO. A DOS based bootable CD contains the IO.SYS, MSDOS.SYS, COMMAND.COM, CONFIG.SYS and AUTOEXEC.BAT files in this boot image. When booted, it can then load an ISO driver that gives access to the ISO image. It is also possible to create FAT based filesystems on CDs that can be booted. I have created Bootable Floppy and Hard Disk Emulation Disks that run DOS, and support writing as well, on DVD+RW and BD-RE Disks.

May not be a bad idea to stop being nagged to update, but probably will not help install an older version.

Downversioning of Flash is controlled by the following Registry Key: HKEY_LOCAL_MACHINE\Software\Macromedia\FlashPlayer\SafeVersions Reduce the limit for the Major Version you are installing, then try again. When you say reduce the limit do you mean changing where it says VERSION? Let me say that I have already installed successfully the latest version 11 of flash for Firefox 3.6.23, and what I see at the moment in the registry is as follows.... I get to the Macromedia folder, then the first folder in the reg is called FlashPlayer, when I click on this I see on the right pane 2 entries, one says Name Default, Data value not set, and also NAME.. Auto Update Test and DATA..."AutoUpdate" Then on the folder below, it's called FlashPlayerPlugin, then there are 4 in the right pane, first is Name Default, Data value not set, second is player path, Un-installer path, and Version "11.0.1.152" Then the folder on the left is shockwave 10, I think that was for the shockwave director, although I thought I had installed version 11 for that, well that is what shows on the add/remove programs list anyway. So at the end of the day there are 3 folders that branch of from the macromedia folder on my registry. Apparently the Plug-In uses different Registry Keys. The Key I posted is used by the IE6 Version of Flash 9. But I used Flash 10 previously. I don't use KernelEx, so I never installed Flash 10. I have never installed the non-IE Version of Flash. This may be why I see the SafeVersions Key. The key and it's contents are as follows: [HKEY_LOCAL_MACHINE\Software\Macromedia\FlashPlayer\SafeVersions] "6.0"=dword:00000058 "7.0"=dword:00000049 "8.0"=dword:0000002a "9.0"=dword:01060000 From this data Flash Version 9 must be no earlier than 262 (106H) or it will not install.

Downversioning of Flash is controlled by the following Registry Key: HKEY_LOCAL_MACHINE\Software\Macromedia\FlashPlayer\SafeVersions Reduce the limit for the Major Version you are installing, then try again. When you say reduce the limit do you mean changing where it says VERSION? Let me say that I have already installed successfully the latest version 11 of flash for Firefox 3.6.23, and what I see at the moment in the registry is as follows.... I get to the Macromedia folder, then the first folder in the reg is called FlashPlayer, when I click on this I see on the right pane 2 entries, one says Name Default, Data value not set, and also NAME.. Auto Update Test and DATA..."AutoUpdate" Then on the folder below, it's called FlashPlayerPlugin, then there are 4 in the right pane, first is Name Default, Data value not set, second is player path, Un-installer path, and Version "11.0.1.152" Then the folder on the left is shockwave 10, I think that was for the shockwave director, although I thought I had installed version 11 for that, well that is what shows on the add/remove programs list anyway. So at the end of the day there are 3 folders that branch of from the macromedia folder on my registry. Apparently the Plug-In uses different Registry Keys. The Key I posted is used by the IE6 Version of Flash 9.

The deadline passed and Yahoo no longer offers the classic version from it's upgrade Page. It looks like you can stay with Classic permanently though if you haven't upgraded. Click on the "help" link in the Upgrade Page text. There is a link in the help page text to stay with Classic. I did this and now I can log into Yahoo Mail Classic without being nagged.

Downversioning of Flash is controlled by the following Registry Key: HKEY_LOCAL_MACHINE\Software\Macromedia\FlashPlayer\SafeVersions Reduce the limit for the Major Version you are installing, then try again.

I already had the full version of his patch installed... or so I thought. When you mentioned this, I decided to open the patch's installer to make sure everything was OK. To my surprise, the installer reported "incomplete installation detected" (or something to that effect). Strange, as it reported success when I initially installed it. Well, no matter. I had it "complete" the installation and after a reboot, NOD32 seems to be working fine once again. Great. Thanks for the suggestions. My RAM Limitation Patch modifies VCACHE.VXD. If you added Xeno86's VCACHE.VXD, you overwrote my Patches. This is why the Installer complained. What version of my Patch are you using?

Then my SATA Patch should bring it to perfection.

Well, as I have said: If you can come up with something better, and I am certain you've got the potential for that, you are more than welcome. Cheers. I do have a redirector that is in my Large File Emulator. Creating a stub DLL with separate stubs for each different parameter count would be simple. Different return codes could be handled as well.

The number of arguments used by many of these functions is not the same as SetLastError. This can cause Stack Faults depending upon how they are used.

I'm not familiar with Cacheman so I have no opinion on it. My Patch can be installed, uninstalled or reinstalled from DOS, so you do not need to Boot Windows to make changes. The Demo time limit only applies while Windows is running. It is not necessary to reinstall your Ghost backup each time. You can boot in Safe mode and disable the Driver, then reboot in normal mode. The /M Option on my Patch will handle large Registries, so you will not need to worry about it causing a problem in the future if it grows.

Your Registry is not very large. After about 12MB the problems increase. The Ethernet is the bigger issue. If you want to be sure about my Patch, try the Demo with the /M option. You do not have to remove the SYSTEM.INI or SYSTEM.CB mods during testing.

Would either of those Ethernet Controllers be a Gigabit (1000MBit) Controller? Do you have a large Registry? There is another Memory issue, that can be aggravated by increased RAM size, that causes the VFAT failure. Gigabit Ethernet Controllers often cause this issue as do large Registries. My RAM Limitation Patch has an option to fix this issue. Try my RAM Limitation Patch Demo with the /M Option and then immediately uninstall it.

I have completed two versions of my Bootable Read/Write Emulators for DVD+RW and BD-RE. The first emulates a Floppy Drive and supports the full size of the Disk. It can be formatted and used like a large Floppy. The second emulates a Hard Drive and can be Partitioned and Formatted using standard tools.

Could you please provide a download link to this driver patch? I want to make certain I'm fully prepared in case any issues spring up along the way. There is no direct link since it is part of my SATA Patch Package. The information is on my Website. There is no Demo to test compatability, but it should work if the Card can run in "Compatability" mode.

In addition to the basic Boot Priority (Floppy, CD, HD etc.) some BIOSes let you choose between individual Hard Drives. On my latest Computer, I have some of my Hard Drives in removable trays, including my Boot Drive. Recently I tried out the Windows 8 Pre-Beta. I removed my Boot Drive and let the Computer Boot from the Second Drive. Then I Installed Windows 8 and ran tests. Afterwards, I reinserted the Windows 98SE Boot Drive and rebooted. The Computer still booted to Windows 8. I had to change the Boot Order to get Windows 98SE to Boot. This BIOS will reorder the Hard Disks if the Drive it expects to boot from is missing and is later replaced. Removing and then replacing your RAID card may have done the same on your Computer.

The VCACHE fix is needed if you go significantly above 512MB. The workarounds or my Patch are not needed until you exceed 1.1GB. This is an issue for Safe Mode as well. The same issues apply, so you can use the information in the "over 1GB threads".

Native Mode and Legacy Mode handle Interrupts differently, and there are Drive Enumeration problems. The unpatched default driver fails and drops out or crashes. The alternative is to run in Raid mode with an appropriate driver, or use a separate card with it's own driver. I prefer the 68K too. It was a lot easier to Program and Debug on my Amiga.

Can you clarify what you mean by "different formats"? Do you mean the interpretation of the Relative Sector field? Correct. The Relative Sector Field of a Chained Record is supposed to contain the offset relative to the First Extended Partition. DOS expects the Absolute Starting Sector in all Type 0FH Records when it should only for the first. In addition, it resets it's copy of the First Extended Partitions Starting Sector, so any later Type 5 Partition would have to be offset from the last Type 0FH Partition rather than the first. I didn't find it, but it is obvious that Microsoft assumed it when they wrote the DOS code. Thanks, Mr Loew. The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version? Joe. The original one. I have only posted one version. Would you mind if I made available, a "combined" patch incorporating this (with appropriate attribution, of course) and my version of Steven's patch? Go ahead. You can simply run my version of Steven's patch, then Mr Loew's. Alternatively, you can do the reverse. Same result. Joe. The Patches are non-overlapping so there are no issues.

To run in Native (IDE) Mode, you need my SATA Patch.

Thanks, Mr Loew. The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version? Joe. The original one. I have only posted one version.

I believe the Patched IO.SYS that I posted last year can be combined with his Patches. A more robust Patch I made later, made his Patches unnecessary.

I was not all that clear while posting around 3 am : that Phantom thing appeared, even though the last partition that IO.SYS found in the extended 0F chain would be a recognisable FAT type, one or more levels "below" the Ext2 and Linux swap. Oh, well, I'm not so sure any more if I've hit a "new" bug or a "new case" of an old bug, or nothing new at all. Sorry ! It doesn't matter if everybody observes : I already knew that. Even though the actual last Partition was a FAT Partition, DOS stopped enumerating after the Linux Partition, so it became the "Last" Partition as far as the "Phantom Bug" was concerned. The "Phantom Bug" is an old issue, but the Type 0FH Enumeration Problem was new, at least to me. Update: I have determined that a Type 0FH Extended Chain Record is treated as an Initial Extended Partition Record rather than a Chained Partition. They have different formats and the Initial Extended Partition Record resets the Start of Extended Partitions value used to define the Partition Offsets. Since the MBR documentation does not distinguish between the Formats of these two types of Extended Partitions, and all other OSes treat them the same, I have designed a Patch for IO.SYS to treat the Type 5 and 0FH Extended Chain Partitions the same.

I think so, too, as I have been using this sytem to multiboot many OSes for many months without problems, including running several OSes concurrently in virtual machines using the raw disk. Your confirmation that I should be safe is appreciated none the less :=) I never looked into this issue until just now. Using Type 0FH Extended Chain Records doesn't produce Ghost Partitions. These are the actual Partition(s), just with unexpected Letter(s). MS DOS 7 does not appear to follow the Type 0FH Chain Records, so the Partitions are not mounted in DOS. Windows 9x rescans and does mount them. If you have multiple Primary Partitions or more than one Hard Drive, Windows is likely to mount them in a different order than DOS should have. I assure you I have one phantom drive - I can actually see the erroneous parameters in a debugger, fortunately DOS refuses to read/write from the phantom - and MS DOS stopping enumerating partitions, as soon as the extended partition which contains my first Linux extended is changed to type 0F instead of 05. It may be dependent on the particular layout of the disk in unspecified ways which you did not reproduce but it is completely reproducible.(Untested Hypothesis : might it be related to my primary type 0C FAT32 partition overlapping cylinder 1023 ?) Sure Windows 9x later does attempt its own reenumeration but 1: it does not remove the fake or phantom entry from the volumes table, and 2. it still fails to find all the partitions afterwards, though it does add one of the primaries that DOS missed. Bizarre, but that is Micros?ft ! Anyway the bug is totally absent IFF interior extended partitions are all marked type 05. Hence my above suggestion, which I am reiterating. Not so bizarre. Since you were modifying an interior Extended Partition, not the last one, I didn't consider the last Extended Partition issue we already know about. My IO.SYS has been patched to fix this. Since DOS stopped enumerating Partitions after the modified Linux Partition, it became the last Extended Partition that DOS saw. This triggered the bug. The Phantom Partition you see is the Second Primary Partition misplaced. Windows correctly mounted it as you saw. The first and third Primaries were not affected. I agree that the Extended Partition Chains must be Type 5, at least until I can Patch it. I don't think crossing Cylinder 1023 should make any difference. I posted a Patch for the Last Extended Partition bug on this forum in the Thread "Phantom Drive Letter" last year.

I have found and Patched a number of bugs including those observed by Phellum and the Last Extended Partition (on the Last Drive) issue you observed above. I think you will be OK with what you have. I never looked into this issue until just now. Using Type 0FH Extended Chain Records doesn't produce Ghost Partitions. These are the actual Partition(s), just with unexpected Letter(s). MS DOS 7 does not appear to follow the Type 0FH Chain Records, so the Partitions are not mounted in DOS. Windows 9x rescans and does mount them. If you have multiple Primary Partitions or more than one Hard Drive, Windows is likely to mount them in a different order than DOS should have.