RetroWish

Hello again, I made some progress in dealing with my second question. I have experimented with EMM386 in the context of HIMEMX. My attempt at just allowing UMA/UMB utilization while blocking the provision of Expanded Memory services (NOEMS NOVCPI) led to quite a surprise. Namely, Win98SE just recognized 384 MB of physical memory!! I wonder if HIMEMX is compatible with some other, hopefully unobtrusive, way to *just* allow UMA/UMB utilization *within* the Win98SE environment...

Hi There. In my "unpatched" system, I have found that any practical combination of (Vcache + RAMdisk) is ok provided the sum total of the two sizes does not exceed 768 MB. Currently, I am using a 256 MB Vcache and a 512 MB RAMdisk. I hope this helps.

Hello @Dencorso, Thanks for the prompt response. That's what I thought too! :>) I speculate that, as experienced "old pros", @Rloew and you have seen your fair share of digital pathologies... To this effect, I would like to ask your opinion about a couple of things regarding HIMEMX and EMM386. First off, when it comes to HIMEMX, is DOS=HIGH required, implied or, even understood? Also, how can one activate the DOS=UMB option? Does one have to use EMM386? Finally, I have read somewhere that there are some drawbacks to using HIMEMX in MS-DOS 7.1 real-mode. Is this true? My second question has to do with the Win98se environment itself (not real-mode). Is there a drawback to utilizing the DOS=UMB option while making darn sure that EMM386 (or whatever works with HIMEMX) does not provide Expanded Memory services (i.e., NOEMS NOVCPI)? Thanks for your patience.

Hello @Rloew, As usual, your response to my latest post has been prompt and, most importantly, quite comprehensive. Thank you very much for staying with me so far! :>) My references to "NRU"/"RU" do not aim at establishing some kind of objective dichotomy. Rather, they reflect my actual experiences and puzzlements with various aspects related to the topic under discussion. Please remember that, in your case, my subjective status may come across as decidedly "yesterday's news" since "you've been there, done that", so to speak. I am still struggling with basic moving parts that are super-foundational by the their very all-encompassing nature (e.g. XMS issues, 4th GB mapping issues etc.) Here is an example. Leyko writes: [What's needed done first is to forget, once and for all, EMM386 and other memory managers; more or less stable work, or even (system) booting can't be guaranteed with them] What is one to make of this? Is he including such venerable "beasts" as HIMEM or HIMEMX ?!!? What aspects of EMM386 (QEMM etc) are potentially problematic here? Is it the Expanded Memory or, perhaps, the DEVICEHIGH/LOADHIGH invokations, or both? You see what I mean? In any case, any and all assistance with such matters is greatly appreciated. Cheers

Hello @Dencorso and @Rloew, @Dencorso, thank you for taking the time to suggest those two books for further technical reading. They will have to wait until summer! :>) Also, thank you for entering my system into the ever expanding "hall of retro-fame"... @Rloew, Igor Leyko's article was a conceptual game changer for me. A million thanks for pointing me in that direction! :>) If it is not too much to ask, could you comment in your usual precise language on the differences between HIMEM and HIMEMX, especially as they relate to VMM.VXD initialization? It appears that HIMEMX (which I *am* using) significantly expanded options, always in an NRU sense and in the context of *this* topic, right? Cheers

Hello @rloew, I am really indebted to you for your prompt and comprehensive reply to my posts. Now that you have pointed the way towards further specific technical enlightenment I will be hitting the books shortly. If I have further questions I know where to come for answers... I will try not to waste your time with information and conclusions that I can access/arrive at on my own, being scientifically meticulous etc. Thanks Again PS. Sorry about the unfortunate spelling mistake. Now I've got it. It is "RLOEW"! :>)

Ok, Rloew In the interest of *finally* doing away with a bunch of misconceptions and "urban legends", I will walk the proverbial extra mile here. Non-Rloew Universe (NRU) -------------------------------------- This is the state of affairs regarding Win98SE *without* a user doing anything like what you have done with your celebrated patch to address the RAM limitations under long-standing discussion. It certainly includes a technical understanding of why the limitations *do* exist in the NRU and, possibly, a conceptual as well as technical blueprint aiming at overcoming them. Rloew Universe (RU) ------------------------------ The starting point is, of course, the NRU. The RU is characterized by the existence of individuals (like yourself ), who, armed with the requisite technical knowledge, proceeded to *do* something about the aforesaid NRU RAM limitations. It also includes all relevant experience relating to the *actually* overcome RAM limitations, whether as programmers/distributors of successful solutions (patches) as well as users of such tools (bug fixes). I hope this sets the stage for an eagerly awaited discussion! :>)

Hi @rloew, For starters, I imagine that you would agree that, given the dry, technical content of this forum, some humor may be welcome. I do have a science background and know rather well the difference between "magic" and "rationalist science". I am truly sorry if my well intentioned humor has offended you. My apologies. As far as I am concerned, this is water under the bridge... Given your prompt response to my post, I assume that you are *still* interested (are you the only one?) in providing key clarifications in an area that, historically, has been confusing, even disorienting, at times. I will try to be as meticulous as I can, given the terminological chaos that may loom large in regards to this particular topic... First off, I would like to excise the term "theoretical" from my terminology. Instead, I propose that we adopt a Boolean distinction along the lines of: 1) Non-Rloew Universe (NRU) 2) Rloew Universe (RU) If I am to *truly* understand the technical realities/constraints underpinning the RU, I sure as hell need to understand those underpinning its conceptual and coding predecessor, the NRU... So, kindly bear with me, if you can. To my statement that "System Properties reports 1,156 MB of physical RAM recognized by the OS" you partially responded: [...with the reported size or the limit] I assume, then, that System Properties is attempting to reflect *some* kind of NRU limit (not "theoretical", but a *practical* limit, nonetheless), right? To my statement that "Adding the Onboard VGA Shared Memory Size of 64 MB yields 1,220 MB" you responded: [The VGA has nothing to do with with the reported size or the limit] If true, a lot of NRU technical information regarding this particular aspect that one comes across in these forums is obviously wrong!! You also wrote: [You set MaxPhysPage to only recognize 1,158 MB of RAM] Well, yes. :>) This is *my* practical NRU limit that I zeroed in on by laborious trial and error. My situation is definitely not unique around here, I understand... Then, you stated: [1,220 is not a theoretical limit. You are already at the limit. The limit varies slightly with the specific configuration.] and [2 MB of RAM is lost due to memory allocation slop.] Yes, we are in total agreement in an NRU sense. There have been numerous statements in these forums to the effect that no one has ever managed to breach the 1,220 MB NRU *practical* limit... By the way, thank you for enlightening me regarding the poor, little 2 MB that are not reported by System Properties. :>) Very importantly, you stated: [MaxFileCache plus any XMS RAM Disk plus some Graphics Apertures determine the amount of System Arena space used for Memory Management. The Kernel and DOS Command Windows use more. The System Arena is limited to 1GB total of Virtual Memory.] Thank you very much for explicitly specifying the important components applicable here. Clearly, the System Arena requires the "existence" of *some* Virtual Memory. Here is where I need big-time enlightenment, I am afraid. To begin with, you stated: [The System Arena is limited to 1GB total of Virtual Memory.] Yes, under NRU conditions, right? What about *minimum* requirements, though? More to the point, you also wrote: [This limitation is why MaxFileCache needs to be specified when you exceed approx 768MB of RAM.] Ok, here is my *main* question. What is the relationship between physical RAM *installed* (not necessarily recognized by the OS as such) and Virtual Memory, always in an NRU sense? I am afraid that I cannot wade through all these "urban legends" all by myself. :>) To boot, aside from the Virtual Memory requirements that you have alluded to, do all (some of) these components utilize *physical* RAM as well, when active/invoked? If so, does the RAM come off the 1,158 MB that the OS recognizes? More specifically, you wrote: [Your Physical Memory allocation is as follows: Windows: 1,158 MB RAM Disk: 384 MB Aperture: 64 MB Unused: 441 MB Reserved: 1 MB (May Vary depending upon motherboard) Total: 2,048 MB ] If "Unused" amounts to 441 MB, where does the MaxFileCache provision fit, if or when actually activated by the OS? Does it consume part of the 1,156 MB that the OS recognizes? (I have already asked this before in a more inclusive framework) I am afraid that I am lost in a dual world where the same components appear to make separate (?) claims on installed/recognized physical RAM as opposed to the Virtual Memory which is the home of the System Arena. Any further enlightenment would greatly be appreciated. Thank You

Below are my system's relevant specs. BIOS Level Data ------------------------- Motherboard = ASUS P4S800-MX CPU Socket = Socket 478 for Intel Pentium 4 Northwood/Willamette processor CPU Speed = 3.0 Ghz Chipset = SiS661 FX and SiS963L Memory Sockets = 2 x 184-pin DDR DIMM sockets (max 2 GB) Memory = 2 x 1 GB PC3200 unbuffered non-ECC DDR DIMMs VGA = SiS Real256E integrated graphics (onboard) Onboard VGA Shared Memory Size = 64 MB Graphics Aperture Size = 64 MB OS Level Data ---------------------- OS = Win98SE Gape's Unofficial SP 2.1 = YES Other Patches = NO Permanent Paging File on a HDD = YES CONFIG.SYS Data ---------------------------- DEVICE=c:\WINDOWS\himemx.exe INSTALL=c:\WINDOWS\xmsdsk.exe 393216 /T SYSTEM.INI Data -------------------------- [386Enh] MinSPs=16 DMABufferSize=64 MaxPhysPage=48600 ConservativeSwapfileUsage=1 EMMExclude=C000-CFFF PagingDrive=G: MinPagingFileSize=131072 MaxPagingFileSize=131072 [vcache] MaxFileCache=393216 SYSTEM.CB Data --------------------------- [386Enh] EMMExclude=C000-CFFF MaxPhysPage=1FFFF [vcache] MaxFileCache=65536 Observations --------------------- System Properties reports 1,156 MB of physical RAM recognized by the OS. Adding the Onboard VGA Shared Memory Size of 64 MB yields 1,220 MB which precisely matches the theoretical maximum achievable without the "magic" of a certain rather well known patch. :>) After sequentially opening up 30 DOS command windows with no problems (resources never even came close to being critical) I smiled and stopped! :>) All RAM drive operations have been smooth and stable with Thorough ScanDisk Test always being successful to the very end (never hangs the computer). Under normal conditions (e.g., other than safe mode), the sum total of the MaxFileCache, RAM drive and Graphics Aperture size physical RAM *provisions* is: 384 MB + 384 MB + 64 MB = 832 MB Now, my system has 2048 MB of physical RAM. If one subtracts the theoretical maximum of 1,220 MB recognizable by the OS (in my case, clearly *achieved* as well), one gets: 2048 MB - 1220 MB = 828 MB This amount is a bit *smaller* than the 832 MB *provision* above which is OK, practically speaking. My hunch is that the 30 DOS command windows draw on "regular" Win98SE memory...

Hi PROBLEMCHYLD, First off, I would like to thank you for your obviously tireless efforts to preserve as well as enhance the practical utility of Win98SE. :>) With Gape essentially out of the picture, you took it upon yourself to carry on with this long-winded project. However, this has not just been a case of someone picking up the baton. Far from it. You singlehandedly changed the philosophy underpinning this project. Essentially, Gape's minimalist approach has been replaced by your rather expansive (maximalist?) approach. This is neither good nor bad, per se. However, having adopted such a radically different approach, you may want to think about certain looming threats (as well as future opportunities) here. In principle, the enhanced and dynamic inclusiveness that the project has exhibited under your spearheading leadership is rather desirable. What is wrong in addressing as many issues as possible, right? Well, I am afraid that there is a downside to this as well. The openendedness inherent in your approach militates against the establishment of clear developmental milestones achievable within reasonable timeframes. Irrespective of other issues, 98SE USP 2.1 has been such a milestone. It has been *there* and has *not* been changing... I believe that 98SE USP 3.0 FINAL is a misnomer. This is not merely a semantics issue. The way that the package has been made available on the Internet for download sows confusion among the ranks of Win98SE enthusiasts. At a minimum, some distinctiveness should be introduced here (a 4 digit build descriptor, perhaps). It harms the reputation of the project to give the impression that the available package is, *indeed*, "FINAL"... To this effect, I urge you to focus your efforts on soon crowning some "FINAL" version as being *truly* FINAL and a *new*, unchanging milestone. If there are still some unresolved issues left, well, then, someone may decide to pursue such things within the context of an upcoming 98SE USP 4.0 BETA 1. :>) The above is offered as well intentioned critique (*not* criticism, yes, there *is* a difference) and in no way detracts from your very welcome contributions for which I cannot thank you enough! P.S. 98SE USP 3.1 FINAL is a distinct possibility here provided that you stick to introducing minor bug fixes and absolutely refrain from getting into new features and areas...