rloew

It sounds like the BIOS only supports 8GiB hard Drives. DOS and Windows 98 (with my Patch) can handle 2TiB. You see the whole capacity because all of the Drive tables are at the very bottom of each Disk. If you try to put more than 8GiB of actual Data on a Disk while in DOS it will become instantly corrupted. You can try filling up the disk with files as an experiment, before you commit the Disk to any real data. Although Windows will not corrupt the Disk, related DOS activity can, so it is not safe. An overlay is required. I had problems with Western Digital's Overlays so I wrote my own. See the BOOTMAN Demo on my website for additional information.

Windows 98 does not properly support SATA controllers that do not appear as legacy controllers. I have a Patch that adds support for Native mode SATA controllers that should allow you to use all of the channels.

I was able to print with SumatraPDF 1.9 using a DLL containing PrintDlgExW and my DLLHOOK redirector. I used a debugged version of jumper's code from Post #8 to create the DLL.

Really? Why is the type of Ethernet of influence? Do the registry and Ethernet share some memory assignment? Yes. They both use space in the lowest 16MB of RAM. Gigabit Ethernet, in particular, uses significant amounts of this memory.

There is no known limit to the size of the Registry files provided that the system is Patched to deal with a memory allocation issue. Using my Patch I have been able to use 18MB Registries. Unpatched, problems occur between 8MB and 12MB depending upon configuration, in particular, the type of Ethernet used.

I checked my Windows 3. It was 3.1 not 3.11. This explains the different addresses. Both of your addresses are equally offset from mine, and they work, so there should be no problems. I don't think there will be any problems unless you try to use it with DOS 6.

A better solution would be to Patch SYSTEM\WIN386.EXE as follows: Windows 3.1 0005EA26: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90 0005EC38: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90 Windows 3.11 00065A26: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90 00065C38: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90 EDIT: Patch was for Windows 3.1, added 3.11 Version.

The wrapper is experimental. I did not publish it. My website has less than 1% of the programs I have written.

Windows 3.11 corrupts the Current Directory Pointer in one or more of DOS 7's Drive Table Entries. Although possible to workaround with Batch Files, it is complicated. I wrote a Wrapper Program around WIN.COM that resets the Pointers.

You need my SATA Patch to use ESDI_506.PDR with the SATA Controller. It is not necessary to disable Multiple Cores as Windows 9x does not know about them. With no other modifications, you can go to around 800 MB of RAM. With limits on the Filesystem Cache you can go to 1.15GB of RAM. You will need my RAM Patch to fully use the 2.5-3.5 GB of 32-Bit RAM available.

I have a Tyan S1590, circa 1998. I flashed the newer BIOS to eliminate the 32GB limit. I later Patched the BIOS to handle more than 128GB and provided a dynamically loaded BIOS for Experimenting. Flashing BIOSes is still Russian Roulette. The best suggestion is to use an UPS to prevent power issues from interrupting the Flash. I would save the old BIOS using the AWDFLASH Program before Flashing the new one. Save it on another Computer. You may want to prepare a Floppy that can Flash the old version automatically. If the new Flash fails, you may be able to redo the Flash using the Floppy but you will see nothing and have no control over the process. I don't think the AWDFLASH Version is too important as long as it recognizes the BIOS chip and the BIOS software. It may affect the setup of the Floppy mentioned above. You can always try one and see if it offers to actually do the Flash, at which point you can decline. The EZ-DRIVE DDO can overcome the 32GB Limit without updating the BIOS. My BOOTMAN DDO can also do this and it supports up to 2TiB.

NTOSKRNL.EXE and HAL.DLL provide the Core functionality for WDM Drivers on NT OSes. When Microsoft ported WDM to Windows 9x they put most of the Functions in NTKERN.VXD and a few in other VXDs. The normal Export/Import model cannot handle this configuration, so Microsoft provided a way to Export Functions under the name of Modules other than the ones hosting them. These Exports are published via Kernel calls, not by PE Export tables. This is why Dependency Walker cannot follow Imports back to these Exports. In addition more than one Module can add Functions under the same Module name. WDMSTUB adds it's functions under the Module name NTOSKRNL.EXE on top of the ones already defined, replacing a few of the existing ones. VXDs can only add Functions in this manner as they do not have Export Tables.

That would be about right with a XMS RAM Disk, "patched" or "unpatched". Each uses System Arena space. The actual limit varies depending upon the Graphics Drivers used.

Or vice versa, perhaps. Actually, it looks like the two methods will be complementary. (BTW, fwd does not patch drivers, it is a DLL extender.) Dependency Walker seems to think so for KS.SYS exports (imported by WDMAUD.SYS). Or maybe those are only standard exports. Where might I find documentation for "WDM Exports" so I can add support? I did some checking. It turns out the truth is a little of both. WDM Modules can Export Functions, in their own Module Name, through their Export Tables as you observed. In addition, they can Export functions under arbitrary Module Names using a VXDLDR Call. WDMSTUB.SYS is a prime example of this. It provides core NT style functionality under the Module Name NTOSKRNL.EXE. Imports are handled similarly to Executables, but the "WDM Imports" come from a database managed by VXDLDR.VXD. VXD Files do not have named Import or Export tables. They can only Export Named Functions through the VXDLDR Call used by WDM Modules. They can do a WDM equivalent of GetProcAddress through another VXDLDR Call. VXDs can share functions though DynaCalls and Win32 Functions, but these are numbered, not named, and are not part of the Windows Driver Model (WDM). As fas as documentation, I would start with VXDLDR.

I'm not sure why you are so obsessed with "NRU". The vast majority of the issues discussed are not affected by "RU" vs. "NRU". Only the following are different: With my Patch, Windows 9x is not limited to recognizing 1,158 MB of Physical RAM. It is able to use as much as 4GB without crashing. There is also a DMA Memory Patch, which fixes a DMA Memory exhaustion issue that has not been discussed so far. I also have a Non-XMS RAM Disk that is completely unmanaged by Windows, so no Virtual Memory in the System Arena is reserved at any time. In addition I have a 64-Bit Version that can use 64-Bit Physical Memory, leaving all 32-Bit RAM available for Windows or other purposes. All other matters, such as the System Arena issue are unaffected. As to your current question. The difference between HIMEM and HIMEMX, that I studied, is the way that Memory Allocated outside of Windows is handled. Since XMS RAM Disks are allocated from memory before Windows is loaded, they are affected by this choice. HIMEM is understood by Windows, so Windows takes over the management of this Non-Windows Memory. To do so, Windows reserves an equal sized area of Virtual memory in the System Arena, to map the Physical RAM of the Non-Windows Memory into Virtual Memory, so accesses to this Memory can be handled within Windows. HIMEMX is not understood by Windows, so Windows is not aware of the Allocated Non-Windows Memory, and does not reserve Virtual Memory in the System Arena. Calls to HIMEMX, to access this Memory, are passed to Interrupt 15H which is handled by Windows. Windows will then Allocate Virtual Memory from the System Arena to map the RAM being accessed. In the case of a XMS RAM Disk, using HIMEM will end up Allocating System Arena Virtual Memory for the entire RAM Disk, immediately upon Startup. If the RAM Disk is too big, Windows will crash. If HIMEMX is used, System Arena Virtual Memory is only Allocated when the RAM Disk is actually accessed. This Memory is never Released, so eventually the entire RAM Disk will be Allocated in System Arena Virtual Memory. With an oversized RAM Disk, Windows will crash as you fill it up.

Unlike DLLs, the Module Names in the WDM Namespace are not owned by individual Modules. Anyone can add new Entry points to any Module. Replacement only requires that the newer code Entry point be loaded after the older one. So there is no need for a driver Patching tool, just additional WDMSTUB like Drivers. Also WDM Exports are not in the Modules Export table.

Going from Rloew to "Rolw" only made things unclear. It does not follow. I suspected that you meant unpatched vs. patched but you could have been referring to something else. The System Properties shows the amount of Physical RAM Memory managed by Windows. There is no limit to what it can show. The limit of interest is determined by an overflow in a table that is used to manage Physical Memory. There are other limits, but they are higher. I don't recall seeing 1,220 MB being mentioned anywhere. The VGA Shared Memory is taken from the Total Physical RAM, but is not related to the Maximum allowed RAM. So 1,220 MB has no meaning. Lucky you. I only got 1,152 MB in my experiments. The System Arena is exactly 1GB of Virtual Memory, by definition. This memory can be mapped to Physical Memory, Swapped to Disk, or unused. MaxFileCache sets the amount of Virtual Memory reserved for the File Cache. The actual amount of Physical Memory used is dynamic, but the Virtual Memory usage never changes. Any active Code or Data must reside in Physical Memory. Windows allocates general RAM from the RAM it reserved at boot, 1,158 MB in your case. Memory Mapped I/O, Adapter RAM (including VGA Apertures), and DOS based RAM Disks, are not allocated from this RAM. But managing this Memory may tie up Virtual Memory in the System Arena to map to it. In your Computer, the File Cache premanently reserves 384MB of the System Arena in Virtual RAM. When in actual use, it will take up to 384MB of Physical RAM from the 1,156 MB recognized by Windows. With 4 different types of Virtual Arenas, 4 different usages of Physical RAM, and Memory Mapped I/O Space, it can get complicated. Even the use of HIMEMX vs. HIMEM has an effect. You should probably read up on Memory mapping and Virtual Memory.

Not familiar with the terminology. Please clarify.

The VGA has nothing to do with with the reported size or the limit. You set MaxPhysPage to only recognize 1,158 MB of RAM. 2 MB of RAM is lost due to memory allocation slop. 1,220 is not a theoretical limit. You are already at the limit. The limit varies slightly with the specific configuration. My Patch is not "magic" it just fixes a number of bugs. 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. This limitation is why MaxFileCache needs to be specified when you exceed approx 768MB of RAM. You would need my Non-XMS RAM Disk, which doesn't use System Arena space, to go any larger. None of this applies. You have plenty of unused RAM. You are nowhere near your limit. 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

My copy is clearly the first.

I have no personal experience with Windows 95 RTM or 95 A. I'll have to refer this question to RLoew, who did some work with those systems during the work on v. 7.0 of the RAM Limitation Patch. If I recall correctly, it does.

So we do agree on this point. BTW, v. 4.20 is still a VxD, right? It's from before he moved on to .SYS. The source code is for a VXD. I don't see any for a SYS File.

I personally prefer the VXD as it is always there just like the NT/2000/XP NTKERN.VXD that it is trying to emulate. From: "PROBLEMCHYLD" <> > Do you think its possible to update WDMSTUB.SYS with the missing exports, > and convert it to WDMSTUB.VXD. There is no point to having a VxD -- WDMSTUB was designed for the single purpose of allowing WDM drivers to work across platforms, and it has to be a .sys file to perform that function. Anyhow, the source code for WDMSTUB came with the book. That means you can use the code as a base to build something of your own with a different name. -- Walter Oney, Esq. 267 Pearl Hill Road Fitchburg, MA 01420 Tel.: 978-343-3390 http://www.oneylaw.com What he says would be true only if he expects WDMSTUB to be used on an NT platform to support a later version. It appears that he is not claiming ownership of the source code, only the name WDMSTUB, so it should be OK to use it and extract the later Code.

I bought the book years ago at a used Book Store. The Source code I have is version 4.20 I have written my own VXD File to add other functions, not in WDMSTUB.

My DLLHOOK Program can add or replace the function independently of KernelEx, but as dencorso said, it may be of limited value without KernelEx.