dencorso

Thanks for great info. BTW, here is shorter link: http://groups.google.com/group/Visual-Studio-NET-2005/browse_thread/thread/4fa74dafe3eb6ef5/ Regards, Roman BTW, you can correct the checksum by using PEChksum, a small command-line app found as part of the freeware PESuite (info) (download link). HTH

What about Flash Player versions 9.0.45.0 or 9.0.47.0? Is there anyone using them? Are they OK for 9x/ME? Myself, I'm still using v. 9.0.28.0, too, and confirm it works OK, but I cannot say anything on the newer versions. And what about the non-ActiveX versions? Please advise. 10/16/2008: I've updated my Flash Player to v. 9.0.47.0, last month, and I confirm it works OK (with IE6SP1).

So, then, you've found another example of a downversion patch that works, this time on a PE file... Awesome, jerichar99! And welcome to Win 9x/ME forum!

Outstanding, Chozo4! But the link you gave is dead already, so here's my two cents: DLMANIP Project page (link). This one is at the Internet Archive, which saves the page but usually not the binaries, so don't download from there or you'll just get a corrupt zip). For download use this link instead. Below are two more links, which can be of interest: Letter Assigner (link), perhaps an alternative solution to the problem and... the MSKB WHDC page on the subject (link), which enlightens but (as in so many other occasions) does not give any usable solution to the problem for normal users, despite being entitled, rather pompously: "Eliminating Phantom Floppy Disk Drives under Windows 95/98/Me"!

ShadeTreeLee is right! Q311561 is a must. Did you try to use Win ME' smartdrv instead? You're running out of a pen drive, having booted it, right? That's awesome!

Hi, vick1111! I confirm your finding: before I was able to open around 20 DOS Boxes, whereas, with HIMEMX and all other things unchanged, I can now open more than 40!

No, /c1 parameter only set cluster size I don't care about it let it set automatically. Parameter /t is important. Well, I think you didn't get my point... I can run XMSDSK with or without the /T switch, and Win 98SE doesn't care. Older versions of Win refused to run without the /T parameter (which loads XMSDSK at the top of XMS, as farther away from HMA as possible), for sure. As I said, Win 98SE does not care whether XMSDSK is at the top or at the bottom (close to the HMA) of XMS, in my experience, so the /T parameter in not fundamental anymore. However, there is a legend that XMSDSK has a bug that prevents it from loading at the top with 2 GB or more of RAM. Since you are able to load and run XMSDSK OK, having 2 GB of RAM, you either demonstrated it is just a baseless legend, or, more probably, have found out yet another strange quirk related to HYMEM.SYS, for it works for you but you are using HIMEMX.EXE. Curiouser and curioser... On the other hand, the /C1 switch directs XMSDSK to automatically select the smallest possible sector number per cluster, what leads to the best possible performance of the FAT, without you having explicitly to set that number. Hence, in my opinion, you should be using it. Frank Uberto's XMSDSK is among the best and most carefully written pieces of software I've ever seen. It rocks.

Glad to know it works! Thanks to you we've learnt quite a bunch of new things about Win 98SE. BTW, you meant to write: "c:\dos\xmsdsk.exe 850000 z: /c1 /y" right? I've also read somewhere that if you rename the ramdisk to any name, except "MS-RAMDRIVE", during autoexec.bat, then it'll show in the swap file setting dialog...

Congratulations, xrayer! Now your system is detecting the maximum amount of memory that Win 98SE can detect (for more see this link). Win ME, on the other hand, is known to detect about 1995 MB, but I've never had any success in devising a patch for having vmm.vxd v. 4.90.0.3003 load with Win 98SE. That vmm seems to be much different from v. 4.10.2226, so perhaps it is impossible to have it working in Win 98SE... Well, about this I can tell you two things: i) It has nothing whatsoever to do with their code, because, although Japheth's HIMEMX is carefully and elegantly coded, Win 98SE's vmm.vxd bypasses all code, literally taking possession only of the data areas (or of the XMS handle table, at the very least). Then again, HIMEMX puts its XMS handle table in its data area, well below 640 kB, in the normal DOS memory arena, while HIMEM.SYS uses the HMA for its table. Even so, I doubt this can cause the different behaviour you and StarRiver observed. ii) Japheth's HIMEMX is *not* HIMEM.SYS, and does not try to fool Win 98SE into believing it is. So Win 98SE's vmm.vxd acts more tactful in its presence, probably forgoing the use of many undocumented hooks it cannot be sure would work, because it is not dealing with HIMEM.SYS and knows it. This probably is the main difference. Be as it may, the fact is that you found a way that works, and that certainly will be of help to many others! BTW, there is a rumour, over the net, that XMSDSK hates to be loaded at the top of XMS, with 2 GB or more of RAM. The same rumour says it stops crashing if you load it without the "/T" command-line switch. Did you try this? I cannot tell you whether this is a urban legend or a fact, because I have only 1.5 GB in my machine, so it's below the purported threshold.

You might want to try patch.exe, from KanastaCorp: it's freeware, very small and very simple to use. I think you should add Xeno86's fixed VCache.VxD to your system, at least because, when in Safe Mode, as you know, system.ini is ignored, so that your system is at risk of crashing from VCache getting too big. It gives you a default of 393216 (384 MB), which is much safer than 800 MB, and you still can keep your MaxFileCache=261120 entry in system.ini file, for normal mode operation. And, finally, if you feel like it and have time to do it, I'd much appreciate to know how your system behaves when limited to 1280 MB and to 1536 MB, with a XMSDSK of 262240 and MaxFileCache=114688. Yes, these are the settings that work in my 1.5 GB system, but I use a 32 MB video board with 64 MB AGP aperture... My guess is that your system won't work with 1.5 GB but may possibly do so with 1.25 GB. Since you are the first to discover that windows 9x/ME in fact does not directly detect how much RAM the system has, but relies instead in what the XMS manager tells it, you should also be the first to explore the tweaking possibilities this knowledge opens up to all of us. You rock!

Well, you can try xrayer's outstanding new solution (link). Good luck!

There are lots of previous posts on that. Read at least this and this. I'd use MaxFileCache=29696 (with ChunkSize=512) and and XMSDSK of 262240 KB for starters. If everything works with these settings, you can test with bigger and bigger virtual disks, until the problem reapears. And don't forget to keep us posted on your findings. HTH

IMHO and experience, the best are: user32.dll v. 4.10.0.2233 (and user.exe v. 4.10.0.2233, they must always be changed together, of course) and msvcrt.dll v. 6.1.9848.0 and the are also the most updated. Did they give you any trouble? Have you tried them? They work OK in My machine. I bet your problem is with the old user32.dll/user.exe pair. The last official ms update is 2231... See: Q260067, Q262830, Q265115, Q277822 and Q291362. And MDGx's site, of course. Good luck!

Hi, rloew! Well, I guess I was unusually terse when I wrote that, thanks for elaborating on the topic. And since you began, let me add that, because it is a hardware problem, it is OS independent, so that not only Win 9x/ME, but also Win NT/2k/XP/2003/Vista, in their 32-bit versions are usually limited to 3.5 GB (for more on that follow this link and the links in it). I think that also GrayPhound's outstanding translation of Igor Leyko's article (link) is an enlightening further reading, for those who want to undersand better the Windows virtual address space layout. Could you please tell some more specifics about that ECS mobo? Is it intended for intel or AMD? What's the chipset and maximum allowable RAM for it? Sorry, I'm aware this is somewhat off-topic, but I just couldn't resist asking...

You rock, blackwire, you sure do!

How do you know the problem is with USB FDD support? Does NUSB 3.1 work and 3.3 break the system?Or are you just guessing? Why don't you track down the problem? It sure is much better to light a candle than keep cursing the darkness. Since you have the board that exhibits the problem and most of us don't, you are in a unique position to help make NUSB even better than it is. Please, go ahead and do it! BTW, I do have both a 3.5 and a 5.25 internal FDD drives in the machine, yet I went ahead and found the way to add USB FDD support to NUSB. While doing it, I did plug one, even two USB FDDs to the same machine. It is pointless to ask "who is going to do something?" because someone will always find a reason to do so... it's part of being human.

@MDGx: I sure think this topic merits becoming stickified... Would you please consider it?

But, i don't think that i'm able to code this in asm. Look out for it. I bet someone already did it in the good old DOS times. Patience and Google together perform marvelous things...

Try removing ACPI and APM (link). This is my own experience. Lots of others say its nonsense (read the posts following the one I gave the link to, and you'll see it), but the fact is it solved many obscure problems of stability for me along the years. Sometimes, however, disabling "use IRQ Steering" gets you into trouble, so test if that is necessary in your system (if all goes well with that on, let it be). And, yes, it is common to have this kind of problem with VIA chipsets, but that's not a VIA exclusive problem. Some other chipsets show it too. HTH

That's not true. I use eMule v. 0.48a without any problems. Have had it on for over 40h, then closed it and used the system some more, then got a perfect shutdown, twice (usually I don't use the system for much longer than 12h without shutting it down). Now, before I removed ACPI and APM (link), eMule used to cause random crashes in my system. So, if eMule doesn't run well, removing ACPI and APM is a good bet. This is my own experience. Lots of others say its nonsense (read the posts following the one I gave the link to, and you'll see it), but the fact is it solved many obscure problems of stability for me along the years. Sometimes, however, disabling "use IRQ Steering" gets you into trouble, so test if that is necessary in your system (if all goes well with that on, let it be). And, yes, it is common to have this kind of problem with VIA chipsets, but that's not a VIA exclusive problem. Some other chipsets show it too.

Java may be writing to the console via BIOS INT 10H... Even DOS text services were implemented this way. What you need is a program that traps all input sent to INT 10H and redirects it to a file. Then, whatever is written to the console will end up in the file. Unless Java writes directly to the video regen buffer... But I doubt it'd be implemented this way. HTH.

Yes: NDIS.VXD 4.10.2226 from Q329128 a.k.a. Q301453 (Requires DUN Upgrade 1.4 already installed!). Refer to MDGx's Win 98SE Essentials page for more info and, while there, consider upgrading also VNETBIOS.VXD... HTH

Try GetVer, from lbrisar's CmdLine Tools, here is the link.

Don't worry! Win XP will read them and write to them all right. And NUSB 3.3 ought to give you acess to them in Win 9x. Don't give up yet, I'm sure you'll get it all sorted out. Frustration is a part of the game, but if it has worked OK before, you can make it work once again. Good luck!

Not anyone I know of. But people elsewere reported favorably on it. See this thread on Tutorials-Win.com: Windows 98 SAFE mode with 1.5GB RAM - Microsoft Windows Forum.