dencorso

Sure, Tihiy!But those are real-life configurations: RetroOS machine's USER resources had a 7% free increase. Mine own machine's USER resources had a 14% free increase. Of course, I've got many real programs in start-up that do IMHO useful things, like Pop Up Killer 1.45.5, HDDHealth 2.1 and Disk Space Monitor 1.0b4 ... At any moment, from start-up onwards, I have at least 16 icons in the system tray. I've trimmed my start-up configuration to the limit. I can't do without any of the programs in the tray. I need the things they do. Now you know why we are talking about "Heaps Expansion" since 2007... Of course, now the name of the subject might as well be changed to "Resources Salvation". But these real-life examples illustrate well the situation: even little improvements in resource management lead to impressive results, because people run many real programs from start-up onwards. Thanks to your efforts, our systems are much better now. You do rock!

Results reported by RetroOS on post #60 in the RP9 thread: I took the liberty to quote it here because it's relevant to this thread's main topic.

Well, despite the error message, USBD is not a VxD, but a WDM driver. BTW, what version of USBD.SYS do you have in your system?

@Tihiy: Thanks for the fantastic RP9! I have, however, a very minor issue to report: I see a flicker, at random intervals, just within the tray area. I'm using a full install of RP9, but not using any skin (i. e. using the "Classic" desktop) and using 16-bit icons, and Clear Type. What I see is as if the refresh were happening too slowly at the tray, so the icon redrawing is perceptible. Sometimes I see two or three flickers in fast succession, then a longer interval without any flicker, then a single flicker, and so it goes... I'm using SYSTRAY.EXE v. 4.10.0.2224 with Winjono's mod for fast USB device removal (the one that comes by default in NUSB 3.3). If you want any additional info, or that I perform any test, please PM me. Keep on the great work! Later addition (in view of the next post): Video: MSI MS-8817 V1 nVidia GeForce2 MX400 PRO32S (DRIVER: 4.13.01.2942). Monitor: Philco 190C (19 INCH). For more details on my system's hadware and software configuration, please follow the > 1 GiB RAM link, in my signature.

Which version of the flash player, Sfor, please?

I've just installed RP9. I did a full install. I am not using any skin, nor 32-bit icons at the moment, but I'm using ClearType. Here're my first impressions: Before RP9, just after system startup: 57% USER resources & 82% GDI resources. After RP9, just after system startup: 71% USER resources & 81% GDI resources. And the resource drain is much slower, and resource recovery (after working for some time and then closing every aplication that was not open just after startup) is much better. Wow! Wonderful! Thanks a whole lot Tihiy! Keep on the great work! You rock!

There is definitely *NO* 137 GB / 128 GiB limit for USB drives in Win 9x/ME. Only internal IDE (PATA) and SATA (when not using Via's VIASRAID.MPD) present this issue. The problem is related to the driver file ESDI_506.PDR can be solved by using the file patched by LLXX. USB mass storage devices rely, instead, on USBPORT.SYS and USBSTOR.SYS. For more, see the related link in my signature.

Sorry, Multibooter, my bad! I thought the links in the News section of SoftLeds at the xFX site pointed to the older versions. Now I've checked it, and found out they all point to the latest version only. I've looked around the net and it seems the're nowhere to be found. Sorry for the misleading suggestion. I was misled myself. PS: Consider, however, that perhaps sending an e-mail to xFX might work: they may yet mantain a back version archive and be willing to send you the version you need. It has worked for me a couple of times in the past, in similar situations.

What about SoftLeds? It's shareware too, but costs less, its latest version is from 2004 and it's from xFX JumpStart, the inventors of the great freeware Pop Up Killer.

Sorry, billyb! My bad! I forgot a necessary step. Now I've corrected my previous post and the missing step is the line in blue. WININIT.EXE is Windows Setup Initialization Utility. It does several things during setup, especially executing the instructions in (when it exists). Those instructions may create, substitute, rename or delete files and/or directories. A WININIT.INI is created when updates, like Gape's 98SESP are run. By typing WININIT before patching you ensure the now newly patched files won't be substituted by unpatched ones from a previously created WININIT.INI that was lurking there. If everything goes well your system will end up having in C:\WINDOWS\SYSTEM\VMM32 a VMM.VxD v. 4.10.2225 patched by the RAM limitation patch. You can confirm it is pached by verifying that the system is now seeing all your 2 GiB RAM, and check its version by finding the file in Windows Explorer, highlighting it, right-clicking on it and selecting the Properties tab, and then the version tab. There should be also an unpatched version of it there, named VMM.BAK, which version should also be 4.10.2225, if you check it by the same procedure. Keep me posted on your results.

@billyb: There's no need to reinstal again. Here's how to solve your problem: I) Boot into true DOS 1) go to C:\WINDOWS\SYSTEM\VMM32 and issue the following commands: ren vcache.bak *.rrk ren vcache.vxd *.rrd ren vmm.bak *.rrk Note: leave vmm.vxd untouched. 2) go back to C:\WINDOWS\SYSTEM and issue the following commands: ren vmm32.bak *.rrk ren vmm32.vxd *.rrd copy vmm32.rrk vmm32.vxd 3) run once more RLoew's patch program. This time it ought to report success. II) Reboot into Win 98SE Are your system seeing all the 2 GiB again? If it is, you may stop here. If not, then open C:\WINDOWS\SYSTEM.INI with notepad and search for MaxPhysPage, and write a semicolon before each line containing that directive. Save. III) Reboot into Win 98SE All ought to be OK now. If so, you can delete all .rrl and .rrk files generate during this procedure. Note: If not, don't delete anything and post here again, telling what happened. In any case, keep me posted. Good luck!

Unfortunately NO. As i said, it fights with buggy programs and resource leaks. Not more. It can't expand heap beyond 64K.OK. Right. Maybe I'm overenthusiastic. Nothing can really expand 16-bit segments beyond 64 KiB, of course. That's built-in on the design of the 80X86 family. But recovering from buggy programs and resource leaks is a giant step forward. Well-behaved programs rarely exhaust the GDI resources. I was thinking somewhat along the line of recovering from unexpected behaviour when I dreamed about the putative "sfix.vxd" (at the 1st quote at the top of post #3). rloew didn't find the ideia workable, but, then again, maybe he was thinking on really solving all types of resource exhaustion. My ideia was, and remains, that even solving just some of them is worthwhile. Now, please, do tell me: will GDI Salvation have a stand-alone version, or do you intend to release it only integrated with UberSkin? I'm sure that a stand-alone version will be much welcome, and reach a broader user base. I think UberSkin rocks. But I do envisage it as a separate entity from programs dealing with the resources issue. And thanks a lot for returning to this discussion, now that it has been restarted. You do rock!

@eidenk: You're welcome! I'm glad you started a topic on this subject once more. @blackwire: Well, Microsoft said it, about Hurricane and Win 9x. And also said: "Upgrade to Helix Hurricane version 2.0 or later." All along, Helix also said that no version of Heap Expander was compatible with Win 95. Note that, for Win 3.1 and WfW 3.11, Heap Expander worked beautifully, all right! But when Microsoft modified the workings of the resources, with Win 95, Helix was at the end of its run, and never developed the Win 95 version. In our tests oscardog and I used the latest available version of Heap Expander, just to see what happened, and to perhaps get some ideas out of it. It seems we got nowhere, after all... But that's past already. For the present, I prefer to believe Tihiy's GDI Salvation will solve once and for all the GDI resources problems, that's why I'm so excited about it. Then, half of the problem will have been solved, there remaining just the USER resources problem. I believe Tihiy said somewhere, around late 2007 or early 2008, that he thought his own approach wouldn't work also for the USER resources. And then he went silent about the resources problem, AFAIK, until that post I quoted at the end of post #4...

The total space used by each Bitmap record I saw was 40 Bytes. The record itself may be 34 Bytes with a 6 Byte Header. I assume the first entry in your sample is what I saw; they were IE Bitmaps after all. There could be other sizes, but I saw a lot of the first type.The actual space used for these Bitmaps is 44 Bytes each if you include the Handle as well. Note: There is no more. This is where the old tread broke off. And now, here're some great news: The quotation below is post #522 from the UberSkin thread: Yep, i figured out GDI troubles. Those crashes / hangs / BSODs are caused by bugs in programs you're using (Miranda as one of them). I've created technology called GDI salvation which successfully fights with buggy programs and resource leaks. Stay tuned.

Alternatively, we could use more 32-bit applications. I don't get it. Why are those things 16 bit for DOS compatibility? No DOS programs uses such things, as they're DOS programs, not Windows programs.

Note: all posts between Oct 19 2007 and Nov 15 2007 did not refer to resources. Roman

Can you please elaborate on this unbalancing or give some links with more detail about it?

Use NUSB 3.3.

VCDFSD.VxD and UDF.VxD are usually compressed inside VMM32.VxD and are expanded just at load time. As VMM32.VxD is created at installation time, when you apply a hotfix to any one of the VxDs inside VMM32.VxD, it is not recompiled, and the hotfix VxD is put instead in the %windir%\SYSTEM\VMM32 folder. I believe you've found a UDF.VxD v. 4.10.0.2223 there, but no VCDFSD.VxD because there has never been any hotfix to it, and hence the original one inside VMM32.VxD is loaded on startup. To see a list of all the VxDs inside VMM32.VxD (or extract some or all of them, if you so want) you'll need Clive Turvey's VxDLib. To see what VxD are loaded and running in your system, in real time, you'll need the fantastic APSoft VxDView.

Indeed it appears as cosmetic, however certain applications may use the reported size in their own reports, thus creating confusion. For example, a simple disk catalogue software (SuperCat) will display the size of all CDFS DVDs as 2GB, which may lead someone into thinking they may be partly burned (open session) or corrupt. May also mislead regarding the required free destination space when copying from such DVD to another support.Thank you for looking into the issue. @Drugwash: I have looked deeper into the problem and, although I have not yet any solution at this point in time, I believe I have, at least, a good explanation of what's happening: I)Windows Explorer, Total Commander, SuperCat, Karen's Drive Info and the superb and simple Karl E. Peterson's DriveInfo, along with every other well behaved Windows program, when trying to determine disk capacity, used and free disk space, first check whether the GetDiskFreeSpaceEX API call is available, and if so, call it to get the desired info, but fall back to the pre-Win95 OSR2 GetDiskFreeSpace API call, when the EX version is not available. That's, BTW, the M$ recommended way to do it. So those programs are doing exactly what they ought to, and are not buggy. II) From Win95 OSR2 up to Win XP (and probably Vista also) both GetDiskFreeSpaceEX and the legacy GetDiskFreeSpace are exported by Kernel32.DLL. There is no bug here also. However, in the case of Win 9x/ME, the kernel is a complex symbiosis among Kernel32.DLL (a 'PE' .exe, a 32-bit executable), KRNL386.EXE (a 'NE' .exe, a 16-bit executable) and VWin32.VxD (a 'LE' .exe, a 16-bit executable driver), so that ultimately all API calls relating to drives (and most of the others as well) have their ultimate origin in the Ring-0 .VxD layer. III) At the .VxD level, all the drive's API are implemented twice: a native FAT (12/16/32) API and an Installable File System API (IFS), for which just two clients are provided: the Network Redirector and the CDFS subsystem. Those two are prsent in windows at least from Win 4 Workgroups 3.11 up to now. The CDFS subsystem is what interests us now, and it consists of an inner layer of stactic VxDs (IFSMGR and VCDFSD) and an outer layer of dynamically loaded VxDs (CDFS, CDVSD and CDTSD). If I'm not mistaken, the inner implementation of GetDiskFreeSpace is in VCDFSD.VxD, which does not provide its sister GetDiskFreeSpaceEX. Why? Because there ate no CD greater than 870 MiB (the very rare 99 min CDs!), the usual, nowadays being 700 MiB maximum capacity, and at the time nobody though that there might be CDFS DVDs. When support for DVDs was added at last, it was support fot UDF, which was grafted to the inner, stactic VxD layer at VCDFSD.VxD, in the form of UDF.VxD! And UDF.VxD adds GetDiskFreeSpaceEX, but for UDF only. Hence the CDFS support remained without support for GetDiskFreeSpaceEX, because CDFS DVDs were overlooked at that point, and remained so up to and including Win ME. Thus CDFS DVDs can only be queried through the legacy GetDiskFreeSpace, which, on overflow, returns the infamous 2.147.450.880 bytes size. Now, then, grafting an all-new .VxD to VCDFSD.VxD, just to provide GetDiskFreeSpaceEX for CDFS all the way up to Kernel32.DLL, is possible, but it requires some really serious reverse-engeneering effort that is way more time consuming than devising the usual patch. Update (Jul 04, 2009): RLoew devised a freeware patch to CDFS.VxD, which resolves this issue. See this post.

I'm positive you run no such risk.

Grab and install the following updates: Q242975brz8, BR291362 and BREXPL98. This ought to get you back to PT-BR. You may have to unpack the latter with WinZip, WinRAR or 7-zip and install their files (user*.* and explorer.exe) by hand from pure DOS, in case you have higher numbered versions already installed...

Since you're using the RAM Limitation Patch, Win 9x/ME ought to see up to about 3.3 GiB and be able to use it. Look closely at the configurations of RLoew's and of Dave_h's machines. I suspect you have a MaxPhysPage directive in system.ini. If so, comment it out and reboot. If not, post again and we can investigate further what's happening. In my own machine I do use a MaxPhysPage equal to the amount of memory that would be available anyway, after the Ramdisk has hidden away half the available RAM, for other reasons (because it seems some process along the GDI stack seems to require the statement). In principle it oughtn't to be needed...

Now, to provide a comparison with another very reliable software ramdisk (this one works only under the Win NT family OSes) here are some more results: Gigabyte i-RAM hardware ramdisk vs. Gavotte's software-only NT-only RRAMDISK GB i-RAM 1.5GiB (Win XP SP3) FAT-32 ------------------------------------------------------------------ CrystalDiskMark 2.2 © 2007-2008 hiyohiyo Crystal Dew World : http://crystalmark.info/ ------------------------------------------------------------------ Sequential Read * : 132.9 MB/s Sequential Write * : 126.2 MB/s Random Read 512KB : 132.9 MB/s Random Write 512KB : 125.8 MB/s Random Read 4KB : 58.6 MB/s Random Write 4KB : 51.7 MB/s *Test Size : 100 MB Obs: The GB i-RAM is a SATA-I device, so its theoretic maximum allowable data transfer is 150.0 MB/s... ===================================== Gavotte's RRAMDISK 1.5GiB (Win XP SP3) FAT-32 ------------------------------------------------------------------ CrystalDiskMark 2.2 © 2007-2008 hiyohiyo Crystal Dew World : http://crystalmark.info/ ------------------------------------------------------------------ Sequential Read * : 308.4 MB/s Sequential Write * : 315.6 MB/s Random Read 512KB : 270.7 MB/s Random Write 512KB : 276.1 MB/s Random Read 4KB : 36.1 MB/s Random Write 4KB : 34.9 MB/s *Test Size : 100 MB Obs: 1)Gavotte's RRAMDISK.SYS is a WDM device that only exists after Win XP has fully initialized. 2) RRAMDISK.SYS v. 1.0.4096.5_200811130 was used for this test.

I've been doing some tests with RLoew's non-XMS RAMDSK32... Here are the results: Gigabyte i-RAM hardware ramdisk vs. RLoew's software-only non-XMS RAMDSK32 GB i-RAM 1.5GiB (Win 98 SE) FAT-32 ------------------------------------------------------------------ CrystalDiskMark 2.2 © 2007-2008 hiyohiyo Crystal Dew World : http://crystalmark.info/ ------------------------------------------------------------------ Sequential Read * : 122.1 MB/s Sequential Write * : 120.4 MB/s Random Read 512KB : 115.1 MB/s Random Write 512KB : 119.4 MB/s Random Read 4KB : 44.3 MB/s Random Write 4KB : 41.0 MB/s *Test Size : 100 MB Obs: The GB i-RAM is a SATA-I device, so its theoretic maximum allowable data transfer is 150.0 MB/s... ===================================== RLoew's RAMDSK32 1.5GiB (Win 98 SE) FAT-16 ------------------------------------------------------------------ CrystalDiskMark 2.2 © 2007-2008 hiyohiyo Crystal Dew World : http://crystalmark.info/ ------------------------------------------------------------------ Sequential Read * : 275.7 MB/s Sequential Write * : 180.2 MB/s Random Read 512KB : 269.6 MB/s Random Write 512KB : 82.5 MB/s Random Read 4KB : 248.9 MB/s Random Write 4KB : 41.0 MB/s *Test Size : 100 MB Obs: using the SYSENTER Method.