dencorso

Try HDINFO... I've never used it myself, but it claims to be able to test your BIOS for 48-bit LBA support.

Wouldn't adding an entry for XMSDSK in IOS.INI solve the compatibility mode problem? See IOS.INI TWEAKS, it is the second tip, just below CD-ROM/DVD MAX SPEED... Whatever the result, please keep us posted on it.

@Offler: did you try DEVICEHIGH=<path>\XMS2EMS.SYS ? What happened? If you can load it high, the page frame will be located in the UMB arena, not in the convetional memory arena...

http://www.mdgx.com/web.htm

1. Yes, the old win98 driver is for the 1,2 & 4Gb (and also older, smaller than 1 GB) Corsair memory sticks with the Prolific 2518 controller. 2. Yes, the new win98 driver is for the 8Gb memory stick running the Silicon Motion SM321QF controller, that I know for a fact, and, I suppose, also the 16 GB and the 8 GB GT (It also works with the Sony Micro Vault USM-E Plus-1GB or 2GB, tha use the same controller, and, conversely, the Sony driver works with the 8 GB Corsair). 3. No. The old driver does work with the 0.5, 1, 2 & 4Gb Corsair Flash Voyagers, but *NOT* with the 8 GB Corsair Flash Voyager (and higher), and vice-versa. Different controllers use different proprietary drivers, which are specific for the family of chips they were written for. If you wish to use one driver only, which will recognize flawlessy all your Corsairs and mostly every other Mass Storage USB devices, you must switch over to NUSB (Maximus Decim Native USB drivers, about which there is a sticky topic on this forum). On the other hand, you may keep the driver you already have and just add the new win98 Corsair driver, because both can live side by side. The advantage of NUSB is that you can recognize lots of other devices too, without adding any new driver. Happy holidays!

EMM386.EXE runs in V-86 mode, which is a kind of protected mode. For some more on DPMI/VCPI look here. @Offler: try XMS2EMS, by Jeff Prosise. It might prove to be just what you're looking for.

The Corsair Flash Voyager 1 GB, 2 GB and 4 GB all use the same driver files, because all of them are employ the Prolific 2518 controller. The Corsair Flash Voyager 8 GB, on the other hand, is a totally different beast, and employs a Silicon Motion SM321QF controller, so it uses a different driver. I've used them all, and still use the Corsair Flash Voyager 8 GB with my Win 98 SE. I also use a Sony Micro Vault USM-E Plus-1GB and a Kingston Data Traveller II 4GB. But I have removed their original drivers a long time ago, and use only NUSB for all of them, nowadays. If you decide to do so, after deleting the device in the Program Manager, I recommend you rename UMSSCORS.inf to UMSSCORS.old (in %windir%\INF), to prevent detection conflict, then installing NUSB, then redetecting uour flash drive(s). Then again, you can leave things as they are and just install the provided additional driver for the Corsair Flash Voyager 8 GB.

Thanks a lot, Offler and Glenn9999, for all the enlightening info and comments. You both rock! Now, here're my 2 ¢... To have Protected Mode without using EMM386.EXE, you can use CWSDPMI.EXE, which comes with lots of software, the Ranish Partition Manager (RPM) among them. Unless you really need you PM interface to be VCPI, not DPMI. Many dos extended programs can use either. Some, cannot. YMMV. But EMM386 NOTR NOEMS as Offler uses it is working just as a VCPI provider IMHO. Maybe there is some standalone VCPI provider, just like CWSDPMI, although I don't know of any.

There is one more thread worth reading: http://www.msfn.org/board/index.php?showtopic=79756

Can you do all the above and still have a stable system with 1.5 GB of RAM? You are the first person I ever heard of that managed to use > 512 MB of RAM *and* EMM386.EXE... I'm impressed!

Yet, the patch has been out for a long time, now, and there is no report of any bug found in it. As many people, me included, are using it from just after definitive release, any major problems should already have surfaced, and none did. IMHO, the patch is the safer solution. HTH

ONGD - FREE - PopUpKiller 1.45.5 --- http://sourceforge.net/project/showfiles.php?group_id=48678

Thanks for the info. From it I guess you have no other place to improve your configuration outside windows. So, please, try reducing even further MaxFileCache to 16384, then restore it to 30000 and try using a bigger MaxPhysPage, but do each modification by itself, and check whether the low memory errors disappear or not in each case.

That's a pity. Never had any problem with it. Then your only easy option is to get Matt Pietrek's PEDUMP.EXE I explained where to get the latest version here. You'll download PE.EXE, and this is a SFX installer, so you can simply open it with WinRAR, 7-zip or your favorite extractor program and get PEDUMP.EXE from inside it whithou any need to run the installer. After you get it try runing, from a DOS box <pedump <path/nameoffile.ext> | find /i "TimeDateStamp" | find /v "00000000">, where <nameoffile.ext> is the name of the PE executable which date you are interested in, and .ext can be .exe, .dll, .ils, .sys, .mpd or a lot of other file extensions. It only works on PE executables, but if you provide it with a file which isn't a PE executable it'll duly complain and exit. I have myself puzzled over this question for a long time too, and here I give you the result of my musings. If you go to MDGx site, the last two lines of this page state the following: Then, by using PEDUMP as described above, getver and dir I compiled this table for the patched versions 1700 and 1710: explorer.exe v. 4.72.3612.1710 size 171.280 PE Timestamp Mon Feb 08 1999 21:04:25 explorer.exe v. 4.72.3612.1700 size 171.280 PE Timestamp Sat Jan 30 1999 00:00:13 Now, you can get IE4SHL95.CAB from three different sources, AFAIK: IE55SP2, IE55SP1 and IE401SP2. From each you can extract a version of explorer.exe, but you'll find that those from IE55SP2 and IE55SP1 are identical, according to fc /b. So this leaves us with just two different versions, which analysis is the following: explorer.exe v. 4.72.3612.1700 size 171.280 PE Timestamp Mon Feb 08 1999 21:04:25 from IE401SP2 explorer.exe v. 4.72.3612.1700 size 171.280 PE Timestamp Sat Jan 30 1999 00:00:13 from IE55SP1/2 So far, these are the hard facts. Below is the explanation I concocted that, IMHO, satisfies all known facts. I believe that explorer.exe from IE401SP2, originally versioned as 4.72.3612.1700 *IS* the unmodded original from which modded explorer.exe v. 4.72.3612.1710 was created, by adding the 256 colors patch and updating some of the icons. Its version was changed to reflect the fact that its compilation date is *newer* than that of the explorer.exe found in IE55SP1/2. A quick and dirty comparison of the relevant files using first eXeScope and then WinHex seems to support my conclusions. So, AFAIK, you already have the file you are looking for. But this is just my opinion...

Hi, EGOvoruhk! galahs pointed you in the right direction. Those threads contain all our previous discussions and findings regarding win 9x/me with lots of memory. I'm glad you got the system to work. As for the out of memory error with DOS boxes, I do have some ideas about what may be happening. Yet, before writing many considerations based on guesses only, let me ask you some questions: Are you using XMSDSK? If so, what settings are you using? What is the AGP aperture you are using? Did you try to use more than MaxPhysPage=38000, after you had set MaxFileCache=30000? And what happened then? Are you using EMM386.EXE or any other UMB manager?

Hi, PassingBy! Check the language code at VS_FIXEDFILEINFO structure (version resource as seen by eXeScope, for instance) and I bet you'll find most, if not all, files are 0x0409. Then, as "American English" = "ENU" = 0x0409 and "British English" = "ENG" = 0x0809, IMHO "ENU" is the best choice.

There is no question that iprop.dll v. 4.0.1381.326 is the highest version of iprop.dll to run correctly on Win 9x/ME. Here (link) is Peter's very lucid and quite concise explanation about version numbers. And as for different files bearing the same version (or even various versions of a file, whatever their version, in cases where version becomes suspect), you can order them from oldest to newest by using the file compilation time (a.k.a. PE Timestamp, link: read posts #912, #916 and #917, please). While iprop.dll v. 4.0.1381.326 should be the file one should use, probably PE Timestamps do support your defense of the Win ME version, don't they? I guess you've found another conundrum akin to the one concerning OLEAUT32.DLL v. 2.40.4522 vs. v. 2.40.4519...

Acheron: Your proposal makes sense. Then again, downversioning 4.90.0.xxxx to 4.10.0.xxxx is a major version change, that implies the patched version has some kind of continuity with previous 4.10.0.22xx VxDs, which is not quite the case. Sure, I know I don't need to explain to you anything about version numbers, but I provide the link to Petr's post about it for any reader who may need it. I had thought about upversioning the patches as 4.90.1.xxxx, then opted for the simpler 4.90.0.(xxxx+1) scheme because: (1) no real good solution exists for perfect versioning of patched versions, as you fully know, for you have participated in an analogous discussion regarding the versioning of LLXX patches in Enable48BitLBA, some time ago; (2) the solution reached there of not changing the version numbers doesn't appeal to me, for I feel there should be an easy way of recognizing a patched from an unpatched file, as PassingBy pointed out to me, even if at first I disagreed, because I had in mind precisely the discussion regarding the versioning of LLXX patches, and (3) my patch changes the file very little to achive its aim, so I opted for the present scheme that denotes this, and it seems safe since MS won't be issuing any more hotfixes for Win 9x/ME. In any case, the files are already released, and modifying their versioning scheme at this point would just add further confusion, by creating pairs of files differing only in their versioning scheme, since it is impossible to substitute all files everywhere after the initial release. So, I think it better to leave things as they are, at this point. But I promise you I'll muse about it for some more time and perhaps use a different versioning scheme for patched files in future releases of other patched files.

If I found Usenet easier to use than web-based forums (which I don't), I'd be posting there instead of here. Agreed! usenet had its moment, way back when. I should know, for I'm on the net since BITNET. Now, nobody even remembers it. One must go where the people are, like it or not. And web-based forums are way better than usenet news, same as search engines like google just show how difficult life was in gopher's times. You can be resistant to change, and BTW, so am I, but that doesn't mean CP/M rules, because it doesn't

@Martin L: Thanks a lot for your swift reply. You rock!

Well, there ain't no "Gold Members" in the list anymore. But there is "Patrons" now. Which is, BTW, your group. Are "Patrons" the new group name for former "Gold Members"? Also, BTW, rating remains disabled (I click on the stars in a profile and nothing happens), ain't it? But the Help doesn't say anything about it. Shouldn't it tell people about it? Happy Hollydays to y'all! MSFN rocks!

Hi, vick1111! If you do have PATA disks installed, I do suggest you install LLXX 48-bit LBA, just to be on the safe side. You are NOT truly safe even with a partition smaller than 127GiB, unless you apply the patch. While it's unneeded for SATA and USB HDDs, it'll do no harm to those types of HDDs, and will protect you from problems with your IDE HDDs. Grab ESDI_506.PDR 4.10.2225 Fix from MDGx's site, it installs the patched file and adds an entry on Add/Remove, that can be useful if ever it causes you any problem. HTH

Well, here is a brief version history for DiskVSD.VxD: 04/23/99 10:22PM 4.10.0.1998 10,194 DISKVSD.VXD Win 98 SE (original distribution, same for FE) 06/08/00 05:00PM 4.90.0.3000 10,140 DISKVSD.VXD Win ME (original distribution) 08/09/00 05:00PM 4.90.0.3001 10,140 DISKVSD.VXD Win ME Q271277 Unpatched Win ME DiskVSD.VxD will not load under Win 98 SE (or FE). Windows'll instead throw a "file is damaged" message and freeze while loading. This can be solved by downversion patching. So here I offer you the patched version of Win ME DiskVSD.VxD v 4.90.0.3001, renumbered as 4.90.0.3002, to reflect the fact it has been patched and runs OK under Win 98SE and FE (but not anymore under Win ME!). Download-link: DiskVSD.VxD v. 4.90.0.3002 for Win 98 SE (and FE) Q271277 "Computer Hangs Accessing Removable Disk Such as Magneto-Optical Disk" corrects a problem documented by Microsoft only for Win ME (it does not necessarily mean it doesn't exist in the Win 98 SE/FE version...), but since many of us are now running the patched version of Win ME DiskTSD.VxD, I think it's advisable to also run this matching DiskVSD.VxD just to be on the safe side. And, in any case, this is the most up-to-date existing version of DiskVSD.VxD known to work with Win 98SE (and FE). As always, the standard disclaimer applies: It works great for me, but YMMV and I can guarantee nothing whatsoever about this patch, and about the use you make of it. By deciding to use it you fully accept that anything you do is of YOUR SOLE RESPONSIBILITY... Moreover, modding files voids the EULA, of course. You have been warned.

Do try Via Hyperion v. 456... Your chipset probably will work better with it than with the latest version.

AFAIK, you'll need LLXX patched ESDI_506.PDR v. 4.10.02225 (since your system is not an IBM notebook) or you'll run against the 137 GB (= 127 GiB) sooner or later. It is needed for IDE (i.e. PATA) disks and for SATA, when they're set to emulate PATA through BIOS. For SATA working as SATA or for USB disks there is no 137 GB HDD limit, and Via Hyperion 4-in-1 or NUSB 3.3 will work without any problems. HTH.