dencorso

Tom Waits - Sea of Love Now, is this a great cover, or what? http://www.youtube.com/watch?v=XVspUm-ZfXI

Welcome to MSFN, AlteredAaron! All I know is, by 2014, I'll be running both 98SE and XP, just as I do now (unless the sky falls on my head first, of course!). And then, there's ReactOS to the rescue, which should be mature enough to help keep XP going strong, by then.

The Benicia is an Asus board. This means that the headers probably are active, and no daughterboard is needed. But the type of the headers is unusual... you'll need four individual four pin (or five pin) connectors for the headers, not two double-row (four or) five pin connectors, which are the most common type. See the attached picture for an example.

True. @ciruss1608: ¡Lea las reglas, por favor! En MSFN, hay que postear en Inglés, pues este site es monolingue. Lo siento. Translation: @ciruss1608: Read the Rules, please! At MSFN, one has to post in English, since this is a unilingual site. Sorry.

Welcome to MSFN!

VMM.VxD is way more sophisticated than emm386.exe. So, in a nutshell, if you exclude both regions I mentioned above (or remove emm386.exe altogether, but I don't think that's really necessary to come to that), *and* install windows using "setup /p i" to instal without ACPI, I bet all will go smoothly. Then, after everything is up and running OK, you may remove the exclusion of the E000 segment, to see whether it really is needed. The whole C000 segment must remain excluded, that much you already know. Then again, that's just my bet. You can't really know if you don't actually try it. But my previous experience with ASUS boards based on the 8237 southbridge leads me to believe that the procedure I outlined should be enough for you to have a stable machine with 9x. BTW, your board actually uses the 8237A chip, but, as you may see from this excerpt from an old press release about them, they are alsmost the same chip.

Amy Winehouse - Back to Black

It's more complicated than that. The 32-bit core interacts with the 16-bit core, and that takes over DOS by patching in-memory and hooking. DOS is not wiped out, it remains there and is taken over by Windows, not removed. Emm386 is also taken over, if present, so that makes the protected mode switches more involved. You probably will be able to install Win 9x by excluding both the C000 and the E000 segments. If you do, run it for some time with emm386, test it well, then comment out emm386 and test it again. Windows uptime, in my experience, is much longer when emm386 is not loaded. If, however, you keep running into trouble on installation, do it without emm386.exe, and if that's not enough, do also disable ACPI from install time (i. e.: use "setup /p i"). Read also this, for further info. I bet you'll succeed in your installation.

Yes, but since there's nothing on D000, according to UMAscan, I think that segment is safe to let emm386 take over... UMAscan is very thorough, and usually reliable.

You should exclude the whole C000 segment: X=C000-CFFF. But how comes you already have RAM at E000, before loading emm386? That's not common at all. Why is it there? I think emm386 is invading that RAM and letting some BIOS routine, probably SATA or USB without its communication area. So I suggest you exclude it too (X=E000-EFFF) and see whether your problems go away. I bet that's the origin of your BSODs. Were I you, I'd try to avoid using emm386 altogether. The RAM you can recover, in case I'm right, is just 64k, the D000 segment. I bet you can make do without it in DOS, and Win 9x/ME don't really need emm386, and, in fact, works better without it. My own board is a case in point. Removing emm386 left my system much more stable. And my board uses the same southbridge as yours do... so my example may very well apply specifically to your case. For the record, here's your motherboard's manual... It may help us.

Yeah. Run it from plain DOS, with just HIMEM, but *without* emm386. This is the way to find out where there's ROM or other memory in the upper memory area, in the 1st MB of ram (the real memory arena). A common boot floppy, having no autoexec and a one-line config.sys with "DEVICE=HIMEM.SYS" is the ideal way of doing it.

No. Run UMASCAN in dos and post a pic of it.

No. C800 - CFFF is the (old) HDD BIOS arena. The EGA/VGA low memory arena is C000-C7FFF. But many newer XVGA boards may go as far as C9FF, and emm386.exe may not detect that correctly. If you have Jeff Prosise's UMASCAN.COM, run it without emm386.exe loaded and you may get a good idea of what emm386.exe is actually detecting (or failing to). Or change the video card for the older one you have at hand, just for testing sake, and see if the issue goes away. If so, then I'm right: it's the video card, all right.

True enough. But what interested me was its purported ability to overcome the standard 16k clusters used by RPM in a easy way. My ideia is to use it to set 32k clusters at maximum, regardless of the rather exotic settings it's purported to also accept. Moreover it seems able to set cluster sizes also for FAT-12 and FAT-16, which is less useful, even if interesting.

The Ranish Partition Manager, although it is not adequate to format the partitions it creates, because of defaulting to 16 kiB, still remains the best free partitioning tool. Nowadays, I'm convinced v. 2.44 is the best one to use. However, until recently, the only free formatting tool I knew of that's capable of reformatting using a user defined sectors-per-cluster number, regardless of how the partition was originally formatted, was Ridgecrop's fat32format (which is needs a NT-family OS to work), since the undocumented /Z switch of the MS Format refuses to work. This may have changed, thanks to Udo Kuhnt and his DR-DOS/OpenDOS Enhancement Project! So, please, do test the new free DR FORMAT v1.0 (see quote above for download link) and report. If it works OK, we now have a DOS only way of doing it.

Welcome to MSFN, pkaji123!

WinRAR 3.93 can open correctly 'dosdrvr.exe'. I confirm 7-zip 4.65 cannot.

On Bumping

Happy new year for both of you, blackwingcat and WildBill! And for Dagwood, too! I'll add a minor request: controlling the font of the disassembly would be very helpful, too. It's always too big in my 1024x768 screen. But my tired eyes forbid me of going to any higher resolution, in my 19" screen.

While this might be true for the former update, the latest doesn't work with Win 98SE unmodified... I just tried and got two error boxes: ================== Error Starting Program The Windows2000-KB2416400-x86-ENU.exe file is linked to missing export NTDLL.DLL:NtShutdownSystem. ================== then: ================= Windows2000-KB2416400-x86-ENU.exe A device attached to the system is not functioning. ================= and the update was aborted. @MDGx: Please, MDGx, as soon as you have time, do create a 9x/ME enabled installer for it!

Why not simply bump? After all this time, it'd be justified, although if nobody responded before I doubt anybody'll now. Great catch submix8c: you do rock! Threads merged. @Krish: Do *not* double-post!

Turns out that both KB981957 and KB2436673 really have problems, due to some uninitialized variables. It seems that only when the user loads many programs on startup, as is my case, that the BSODs manifest themselves. Thanks to WildBill, who found out the problem and issued a patch for it, the problem is now really solved. WildBill's patch is findable here. Thanks, WildBill, you do rock!

Yes, I guess so. But note that there is a difference. When you set TEMP, TMP and/or TMPDIR (some old dos programs look for this latter one instead) from CONFIG.SYS, these settings superceed anything present in the registry. When you do it through the registry, these settings still superceed whatever settings are put in the AUTOEXEC.BAT. Settings from AUTOEXEC.BAT will only stick if not set also from the registry or CONFIG.SYS. So, if you don't want to have conflicting locations for the TEMP dir, the best idea is to set those three variables from CONFIG.SYS, so as to ensure they'll be the same in Virtual Machine #1 (where Windows runs) and all subsequent VMs (which are DOS Boxes). And, yes, Win 9x (or DOS 7+) CONFIG.SYS understand the SET command, of course. You can use it even to set the PATH from CONFIG.SYS.

Under Win 9x one can set TEMP and TMP from CONFIG.SYS, while under ME that may be done in the registry, if I'm not mistaken (about ME, of 9x I'm sure).

Thanks! HTH to keep everybody informed on the latest updates, as well as, to keep all relevant discussion in one place, for easier reference.