dencorso

Hi, Offler! Whence can I get ijl15.dll and msvcp70.dll, please?

Way to go, diskless, way to go! Keep on the great work!

What about Thalassa ?

Hi, blackwire! I've done some more testing (always with the folowing options selected in the view menu: Numeric Charts, Always on Top and Hide Title Bar), and was unable to reproduce your issue on 10 different machines, by now. Of course, my testing has one bias, because all the machines I've tested it in had AMD processors, so I'd warmly welcome test results from other users of Intel processors. There might be something there. I doubt the powerstrip can be related to your issue, as I would any other kind of overclocking (overclock issues usually crash the machine, instead of causing unusual behaviour). It is important to test it in Numeric Charts Mode, because the patch corrects a rounding issue, which is difficult to see in this mode, but probably impossible to percieve in graphic modes... I've also disassembled the relevant part of the code from both files in my release, and can confirm the patch is applied correctly, and is identical to the disassembly provided by Geoff Chappell in his original bug report. I fail to see how the code change Geoff's patch implements could be causing the issue you reported, though. So, it seems that what you are experiencing must be due to some quirk peculiar to your installation. Did you try the Win ME version in your system? Does it cause the same issue? A side note: the only occasion in which I've had CPU usages close to 100%, consistently, was when AVG was running in the background, although it didn't stay solid in 100%, but did so for a series of short periods. Best wishes.

Yes, soporifc, you're right, at least in part: If you check the file version with getver.exe, it will report 4.90.0.3000, whereas if you select the file in Windows Explorer, right-click on it and select Properties, you'll find 4.90.0.3001... Of course, as it loads OK in Windows 98SE, it is the patched version, so Properties is displaying the correct value, but, at hexadecimal file offset 4717, B8 must be changed to B9, to update also the hexadecimal file version, the one getver.exe reports...

blackwire, thanks for the report. I failed, however, to reproduce the issue you reported, in all test scenarios I tried. Can you provide me with more detail, please? And thanks for the pointer to Process Explorer. I do use WINTOP and the System Monitor, but other tools are always handy. Cheers!

Hi, Xeno86! Download them from this link. HTH. @everybody: Do you all want real stone age? Try the EDVAC or the ENIAC. Then again, without them we wouldn't be here today, ain't it so?

No. VMM.VxD 4.90.0.3000 does not work with Win 98SE. It refuses to load, even after downversion patching, as I had predicted elsewhere. But now I know for sure, because I've tried it. So this is the first known example of Win ME .VxD file that won't load in Win 98SE, despite what version it claims to be...

A long time ago, Geoff Chappell, author of the classic book DOS Internals, reported (in June 07, 1999) a math bug in both Win 95 and Win98 FE versions of SYSMON.EXE (here: System Monitor Rounds to Thousands). Geoff also provided detailed directions for a corrective patch of these versions of SYSMON.EXE. And, of course, it also applies to the Win98 SE version of SYSMON.EXE, because it is identical to that of Win 98 FE, except for its creation date and time, both reporting to be v. 4.10.0.1998. But, in June 08, 2000, one year later, SYSMON.EXE v. 4.90.0.3000 was released in Win ME, and my analysis shows it has the same buggy code inside as that of the Win 98 version, showing that Microsoft disregarded completely Geoff's heads up. His patch for the Win 98 version solves the problem for the Win ME version too, but, of course, has to be applied at different offsets (30C4, 30D4 and 30DA, respectively). Since this issue remained unaddressed up to now, I here offer you Download-link: both patched SYSMON.EXE for Win 98 (SE and FE) and for Win ME Inside SYSMON.7z one finds SYSMON.WSE and SYSMON.WME, which are, respectively, the files for Win 98 (SE and FE) and for Win ME, patched according to Geoff's instructions. Of course, before using one of these files to replace that in the %windir% folder, it is necessary to rename it from .W?E to .EXE. For both files, I've increased the version number by 1, to reflect the fact that those are patched files. Users of 98SE2ME should use the Win ME file, of course. As always, the standard disclaimer applies: they work great for me, but YMMV and I can guarantee nothing whatsoever about these patched files, and about the use you make of any of them. By deciding to use one of them you fully accept that anything you do is of YOUR SOLE RESPONSIBILITY... Moreover, modding files voids the EULA, of course. You have been warned.

Hi, erpdude8! You're right: the max size for XMSDSK is 2Gb. That's because it is FAT16, which has an upper upper limit is 2Gb. It also causes XMSDSK to behave strangely and throw errors, refusing to load, with more than 2GB of RAM installed. Although I never faced such a problem myself, I've read that, strictly for these cases, the solution is to let it load below the top of the memory, by ommiting the "/T" switch, which is otherwise mandatory for use with Windows. See the last lines of this TechArena post (#2), by Mark-Allen Perry, about it. BTW: no, it cannot be made FAT32, because its format is part of how it's coded...

Hi, risk_reversal! I'm sorry I misinformed you. I've never seen any Corsair Flash Voyager smaller than 8GB with an SMI chip. But your info shows that Corsair has dumped the Prolific chips for the smaller Voyagers also. Thanks for the heads up!

Thanks, but as one of the posters in the other thread noted, I'm not in a hurry to get rid of ACPI (if I understand correctly, the 3 to 4 GB area really matters, and ACPI seems to hold a lousy 20MB there), especially since disabling it in the BIOS would shoot it under my other OS (XP) too, I suppose. Note that my how-to was written with other purposes in mind. For a double boot machine, I'd recommend to skip the BIOS part, so as to leave ACPI for the other OSes. And, then, remove ACPI from Win 98 only (this causes Win 98 to switch to APM). And the remove APM also from Win 98 only. As well as disable NVRAM/ESCD updates and IRQ Steering in Win 98 only. It can be done and works OK. What remains to be seen is whether this also can solve your memory problem.

Hi, vick1111! Please try: c:\ramdisk\xmsdsk.exe 262272 Z: /c1 /y **yes, without the "/t", despite all you can read about it: there are reports this may solve your problem.** It's said it works for 2GB or more RAM. I never tried it, because I've not encountered such a problem, probably because I've got only 1.5GB, I guess. Good luck!

Hi again, GreyPhound! I just finished reading it and found a small typo, that needs correction: This notwithstanding, you did a fantastic job! Thanks again!

1) This looks as a memory conflict to me. Isn't there any typo? 2) Same here. Isn't there any typo? Now, I see the following free memory spaces: E4440000-E44FFFFF = C0000 E4500800-E4500FFF = 00800 E4501100-E4501FFF = 00F00 E4502100-FEBFFFFF = 1A6FDF00 FED00000-FEDFFFFF = 100000 FEF00000-FFF7FFFF = 1080000 Which totals to 1B93FE00 => 451839 kB on doing Igor Leyko's calculation. Subtracting a VCache of 65536 KB, the result is 386303 kB... But note that this is fragmented real memory. And it seems not to be enough for the Ring 0 VM (all Windows VxDs) and additional DOS Boxes (DOS VMs). I'd do a backup first and then... I'd try to remove ACPI (and APM) from Win 98, to liberate some more memory on the 4th GB... I've posted a how-to here (link) some time ago, for other reasons, but it might solve your problem. Then again, this is just a wild guess... Anyway, good luck! And please do keep me posted on it.

Awesome, GreyPhound! Thanks so much! ======= @Max Monroe: Pleases try this extreme configuration: 1) in Config.SYS: (i) NO EMM386.EXE (ii) NO XMSDSK.EXE (iii) HIMEM.SYS /NUMHANDLES=96 /TESTMEM:ON /V 2) NO Autoexec.bat at all 3) in System.ini (i) under [386Enh], MaxPhysPage=38000 (ii) under [VCache], MinFileCache=0 MaxFileCache=29696 ; 29M ChunkSize=512 >>> Note that MaxFileCache=29696 really, this is not a typo. <<< 4) AGP aperture 64MB ...and let me know what happens. Good luck!

GreyPhound: Awesome! You rock, you really do! As for your questions: 1) For some reason I don't understand, the 'attach file' option has been disabled in the "Windows 95/98/98SE/ME" main forum, for as long as I can remember, although it is enabled in the "Unofficial Win98 Se Service Pack" subforum... 2) IMHO, it'll be much better if you can add part 1 to your original post, regardless of the final size of the post. After all, if you do that, every one who reads your translation, from now on, will be able to read it in order.

So, I'd guessed right! Thanks a lot for your swift reply. You rock!

Ninho: Thanks for the heads up. I've, now, corrected my post. But I forgot to answer your question, so I'm doing it now: Yes, you've got it right. That's exactly what I meant. And XMSDSK is just a good example of a program that allocates XMS from DOS (run from autoexec.bat or from config.sys), before Windows even begins to load. There are other examples, but I think ramdisks are the most useful nowadays. I think Igor Leyko didn't cover this subject in his article because it would render even more complicated a subject that, as you yourself have said, is not easy at all. But in the present thread it is unavoidable to consider the case of ramdisks, because, IMHO, they are a must for systems having more than 1GB of RAM installed.

Way to go, GreyPhound! Thanks a whole lot! You do rock! BTW, let me ask you one thing, please: does, perchance, "железа" mean "hardware"?

Sure. But it's really alive and kicking. I tend to 5 separate Win 98SE machines, besides my own. And I bet many, if not most, of the people here in this forum have/know of/tend to more than one 9x/ME machine each. Win 9x rules!!!

I do.

@diskless: You're doing nothing wrong, but with just 512 MB you'll NOT run into any of the problems/limitations that appear on machines with thrice or more that amount of RAM, no matter what strange configuration you use. My point was that during startup Windows remaps all XMS memory already alocated before starting Windows to addresses in the fourth GB (downwards from 4 to 3 GB, starting at the highest free address) just as if that memory was owned by some hardware device, and all free memory that it can see (up to 1156 MB, AFAIK, with an unpatched VMM.VxD) in a continuous block starting at 0 GB upwards, and I have no firm idea about what it does with any remaining memory (but it seems reasonable to imagine it would be mapped just above the end of the memory Windows detects). To form a picture of what I'm talking about, just imagine the following case: 2 GB of RAM of which 512 MB is allocated to XMSDSK and 1156 MB as normal memory: where will the remaining 380 MB be allocated? Bear in mind that HIMEM sees it all... And then, there still remain the AGP aperture and VCache to consider, but such memory is mapped in the 4th gigabyte, anyway... @gosh: very true. We're still looking for ways to overcome the Resources limitation. @Ninho (in view of the post below): Thanks for the corrections, you are right, of course! And yes, I am talking about virtual memory addresses. Windows organizes its virtual memory arena as 1GB for devices and the like (the 4th GB) on top of 3GB of system's and applications' space, whatever the real amount of RAM present.... I have now corrected the text above, using a red font for the corrections. You rock!

First of all: remove EMM386 from your CONFIG.SYS! It's not required for windows and this results in memory management way worse than standalone VMM.VxD. And in the configuration you are using it, it is not able to provide UMB, so it is pointless to use it anyway. And don't forget to change the DOS statement to "DOS=HIGH" without the ", UMB". Now, Exception 0E is a Page Fault. XMSDSK is trying to access memory that isn't there. I think I know why, so bear with my somewhat longish reflection below, please. Some time ago, Tihiy (in this post) pointed to a russian language page, by Igor Petrovitch Leyko (Nov 03, 2005), about win 98 memory problems (link), and while no automatic translator did a good job at translating it, Google Language Tools gave me a good start, and from that start I've done my best to produce a good enough English translation of a short excerpt of that page, which I find relevant to the present discussion: Just to avoid any misunderstandings, let me say that, in my own system, when I perform the above procedure, I find, as the device with lowest memory address range: "EC800000-EC8000FF Via Rhine II Fast Ethernet Adapter" and hence, by doing the calculations with EC800000, reach a value of 729088 kB. But the real problem is what does this value really mean? Well, my own experiments show that if I set MaxFileCache=729088 or to any value above 131072, I get "Insufficient Memory to Initialize Windows" and the system simply doesn't start at all. Yet, MaxFileCache=131072 still leads to a "There is not enough memory available to run this program" on starting a DOS box, usually the third or the fourth, sometimes even the first. So I settled down to use MaxFileCache=114688, and now I can start 28+ DOS boxes, before getting the "There is not enough memory available to run this program" error. All this using a XMSDSK of 262272 kB, and having an AGP aperture of 65536 kB. But if I expand or reduce the XMSDSK size, the number of DOS boxes I can open diminishes or increases, respectively. Further tests seem to indicate that the memory value reached per Igor Leyko's proposed calculation is the total memory pool available for XMSDSK, VCache, the AGP aperture, and the DOS boxes. In my system this means 262272+114688+65535=442496 and 729088-442496=286592 is the free space my DOS boxes use, when created. Bear in mind that my system has 1.5 GB of RAM and I'm using MaxPhysPage=48400 (1156 MB) now. Be warned that, except for the text from Igor Leyko that I cited, all the conclusions presented here are mine own, based solely on my limited experiments on my own computer, so: (1) I may be wrong and (2) even if I'm not, YMMV. Happy holidays!

If you mean MDGx's 98SE2ME, then yes, very. From e-Bay, from Alibris or from a bunch of other used goods resellers. Right, but it's already very good, probably it'll change very little til final release.