SweetLow

Pure VESA 2D driver does not use WS2.

This is PM handling of ;INT 33 - MS MOUSE v6.0+ - SET LANGUAGE FOR MESSAGES ; AX = 0022h ; BX = language V version accepts 8 [standard] languages, F - 10 (some additional 2 lanuages and IDK what they are). It's strange but the variable where this value saved is referenced from other places in code - but there is only 8 languages processed. No. It is workaround against buggy hardware - some PS/2 5-Button Mice. In addition to standard unlocking sequence of Set Rate 200, 200, 80 it executes (when Registry "Enable Q318307" key is set to 1) nonstandard sequence of Set Rate 200, 200, 60 before standard sequence. But problem still exists - VMOUSE.VXD from Q318307 has version 4.10.2225 (for windows 98SE for exаmple) and previous version from Q254660 is 4.10.2223. So there is no such thing as VMOUSE.VXD 4.10.2224 and that is the real misterious.

It does. Sorry. Typo. It is burNmem. https://github.com/Baron-von-Riedesel/XMSTools There are different internal results for Windows Memory Manager. And using DOS tools has much more strict effect in memory limiting.

If you need to limit memory - use memory limiter: burmem/limitmem/xmsres. Do not use this execept for Safe Mode. But as you use RLoew's patchmem - do not use at all.

Yes. Cache realization in vcache is limited both by physical and virtual memory. And virtual is more restrictive with maximal available values.

Vcache uses system arena with 1GiB size.

Yes. PCI devices have independent resource management (until they emulate some ISA devices with fixed resource set, of cource). There is simply no "alternative address ranges" for PCI devices as there is no "main address range". "boot address range" and "current address range" - and that is all.

Virtual V86 Mode. The same as you are running DOS applications under Windows. It's just the different sources of the same information (and some of them can have bugs too). And yes, search gives the old KB article from MS still: https://support.microsoft.com/en-us/topic/how-to-disable-pci-bus-irq-steering-in-windows-695c360f-1aae-471e-878e-07ff971b8e02

Because modern OSes: 1. Use modern hardware parts of PC by default (IRQ related - APIC and MSI) that make probability of conflict far lower. 2. Can use modern ACPI - which reports used MB resources correctly. 3. Have some differences in behaviour of Resource Manager. 4. Do not have some bugs like this: https://msfn.org/board/topic/186768-bug-fix-vmmvxd-on-handling-4gib-addresses-and-description-of-problems-with-resource-manager-on-newer-bioses/

I know two and recommend only one. And it is discussed right on this forum on the first page - ramdrv4m. Of course. Because Windows is compatible with DOS drives by default.

The only things you really need are .INF, NDIS2 binary and 1 reboot. Windows do the rest as it natively supports NDIS2.

No, it is not only visual. And why do you use DOS solution for Windows 9x? It has native ramdrives.

You need the Windows .INF in addition to NDIS2 or ODI driver binaries. It's pretty easy to do it yourself. This is my .INF for Broadcom "NetLink (TM) Gigabit Ethernet" (PCI\VEN_14E4&DEV_16B5) http://sweetlow.orgfree.com/download/b57_w9x.zip You shoud add your device PCI ID (and name if you need some other name) in appropriate sections.

Check this problem (use translator) and solution: https://forum.ru-board.com/topic.cgi?forum=62&topic=31453&start=100#9 https://forum.ru-board.com/topic.cgi?forum=62&topic=31453&start=120#16 And pay attention to my tool to set/dump MSR/MTTRs state (MTRR_VAR.EXE particulary): https://github.com/LordOfMice/Tools/blob/master/msr.zip to compare the state of MTRRs with 2G and 4G RAM. As you described your problem - no. As I said I suppose now that this is not the problem in DOS or Windows but it can be fixed.

And why do you think that you got exactly memory size problem in Windows after that? This can be really some other problem like wrong MSRs programming by BIOS with large RAM size.