Usher, on 10 April 2010 - 12:06 PM, said:
dencorso, on 09 April 2010 - 11:52 AM, said:
Usher, on 09 April 2010 - 11:09 AM, said:
dencorso, on 08 April 2010 - 09:45 PM, said:
5) to access "Safe Mode" with > 1 GiB RAM you'll need both the VCache.VxD modded by Xeno86 and xRayeR's patch to IO.SYS.
Are you sure? Did you read my posts about system.cb in safe mode? They are here:
http://www.msfn.org/...de-t142953.html
If my solution works for safe mode, it can be more useful than binary patches.
@Usher: I've read it, rest assured.
Not enough carefully, I'm afraid.
Usher, on 10 April 2010 - 12:06 PM, said:
I have written in my posts that I have NO machine with > 1 GiB RAM for testing now. You have, other users have, but I do not have and I will not have such a machine in the nearest future.
Carefully enough. I only missed the fact you don't have a machine with enough RAM to test your idea.
There is no need to your adversarial posture. My only interest is to help. And I feel that, when striving to do so, it's more sensate to propose time-proven solutions than experimental ones, as the fist option. That said, thank you for posting your interesting idea and also for calling my attention to that interesting old thread by Tihiy.
Usher, on 10 April 2010 - 12:06 PM, said:
And I wanted to change it to be more logical, so I reordered the steps:
dencorso, on 09 April 2010 - 11:52 AM, said:
1) Applying MS
KB311561, then rebooting.
Official MS patch is a must have. It should be installed with all other MS patches, f.e. using unofficial Support Pack (SESP). You may recommend SESP install.
You also didn't read the OP carefully enough. The OP says he's already installed SESP 2.1! However, I recommended installing
KB311561 just to be on the safe side, since, for me, it's evident he's running Win98SE in an unstable configuration, and did not do the time-proven tweaks for being able to use safe mode.
Usher, on 10 April 2010 - 12:06 PM, said:
dencorso, on 09 April 2010 - 11:52 AM, said:
2) Adding a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.INI
This is not for safe mode. In safe mode SYSTEM.CB file is used, not system.ini. You should recommend also editing SYSTEM.CB.
While it would, AFAIK, be harmless to recommend the change to SYSTEM.CB, no amount of prodding will be enough to make me use krelian as a guinea-pig for your new method, since there are time-proven alternatives I'm familiar with and know for sure that work.
Usher, on 10 April 2010 - 12:06 PM, said:
dencorso, on 09 April 2010 - 11:52 AM, said:
3) Installing Xeno86's modded
VCache.VxD (after this, usually, no MaxFileCache line is needed in SYSTEM.INI)
There is no need for this patch. It is just hardcoded setting from [vcache] section in system.ini/system.cb. Editing ini files should be recommended - this way users can test different settings and find the best settings for their machines.
That's simply not true. While Xeno86's modded VCache.VxD changes the default value for VCache, which is only used when there is no settings in the [vcache] section of SYSTEM.INI/.CB, it duly abides by any settings found there, when they exist. So it's a better all-round alternative to the original MS VCache.VxD, and should be used, at least, by all users running 9x/ME with > 1 GiB RAM. In fact, while it caters for the fact that there is no [vcache] setting in the original SYSTEM.CB, so that it obviates the need for this setting both there and in SYSTEM.INI, it'll also abide by such a setting present in SYSTEM.CB. Hence, Xeno86's modded VCache.VxD won't prevent anyone from tweaking their .INI and .CB files to their liking, in no way, but sets a more secure background to fall to, if needed. Had you read carefully enough
VCACHE fix attempt, you'd be cognisant with all I said above, and there would be no need for me to reply to this particular point.
Usher, on 10 April 2010 - 12:06 PM, said:
dencorso, on 09 April 2010 - 11:52 AM, said:
4) Adding
HIMEMX.EXE to C:\WINDOWS, and then renaming it to HIMEM.EXE
5) Running xRayeR's
w98iopat.exe, in True DOS, from C:\
6) Creating a CONFIG.SYS in C:\, containing the single line "DEVICE=C:\WINDOWS\HIMEM.EXE /NUMHANDLES=64", without the inverted commas.
The changes in 4-6) are for using memory manager other than MS HIMEM.SYS. Once again, I have no machine to test it with > 1 GiB RAM, but from FreeDOS mailing lists I know Japheth's HIMEMX.EXE may still have some bugs and compatibility issues that are not solved yet.
Japheth's HIMEMX.EXE v. 3.32 does indeed have some remaining bugs, the ugliest of which is creating orphan handles in some very contrived scenarios. It also simply ignores one switch, the TESTMEM switch if I remember right. And its implementation of XMS 3.0 functon 88H does not return the "highest ending address of any memory block" in the proper format (viz. in kiB). I know that from first-person experience, both from testing HIMEMX.EXE extensively and from analysis of the released source code. However, none of those bugs create any problem serious enough to prevent the day-to-day use of HIMEMX.EXE, which is a convenient tool for postponing XMS related problems caused by too much RAM for an unpatched VMM.VxD. For more on this, you should read again this most interesting post by
RLoew on HIMEMX's limitations. And, BTW, HIMEM.SYS v. 3.95 also has standing bugs (three, at least, which I intend to address by releasing a patch for it in the near future), but that also doesn't prevent it from being usable and useful.
Usher, on 10 April 2010 - 12:06 PM, said:
dencorso, on 09 April 2010 - 11:52 AM, said:
For even better results, one should instead use RLoew's RAM Limitation Patch, of course, but that's not for free, and the above procedure is the most reliable way to do it completely for free, in my experience.
In general, your recommendations are for advanced users, while my solution could be good also for testing by newbies.
And you know there is no need to use as much RAM as it is possible in safe mode. It is enough to have any simple, safe and working solution. Just someone ought to test it.
Now, here are various points, which have to be answered separately:
- RLoew's RAM Limitation Patch is not free, but is absolutely user-friendly, and can be applied with success by even the most unskilled of newbies. And RLoew gives outstanding good support for his customers, on top of that.
- Other solutions are free, but less user friendly. And there is only us, other users, to give what best support we can muster for other users trying to apply them.
- Anyone who seriously intends to run Win 9x/ME nowadays, especially with > 1 GiB RAM, must seriously intend to become an advanced user, if he isn't already. Whoever wants easy should look elsewhere, because the one thing the Win 9x/ME world cannot be anymore is "simple": you have to strugle with hardware, drivers and the like every single day, and to do that minimally efectively you must be able to work both from True DOS and from within Windows, as needed, as the bare least (or, at least not be afraid to learn how to, when needed), and also welcome help in the form of time-proven bona-fide unofficial patches, that caring users provide to obviate you from the need of using debuggers/ disassemblers/hexeditors yourself.
- I'm not, and never was, against the testing of your proposed solution. But, in principle, that should be done by experienced users solely, until proven to work well. What I'm certainly against is skipping over such careful testing and, instead, using new-users-in-need as guinea-pigs. That's all. Now, in the specific case of your proposed method, as it just involves editing SYSTEM.CB, I think the testing can cause no harm, so it's up to krelian to decide whether he wants to do it or not. In any case, it's counter-productive to have two users advising krelian to do completely different things at the same time.
krelian.zip (4.38K)
autoexec.txt (1.08K)
Frontpage
Forums
Tutorials
Members
Calendar
Subscription
Donate
Links
Contact 
Help
Back to top