The RTL8111C was the last Realtek chip with proper Windows 98 support. Rloew posted on another forum about a driver that works with later chips, but only at 100 Mbps.

Unfortunately, I can't find that post at the moment with the driver information (I've used it in the past). You might need to do an internet search when you have the time.

Ahhhh patchmem /m might fix it. Cheers

https://github.com/JHRobotics/patcher9x/blob/ … hmem-manual.txt

If the Linux driver is any guide the init routine for D has an extra variable

Nope.
Split8mb failed too

Rloew posted about a beta driver for slightly newer Realtek chips on Msfn.org a while back, but I'm having trouble searching for the post on my phone.

I actually have a copy of the driver at home, but I'm at work for the next few hours.

I found RLoew's post about the RTL8111D. It's about three quarters of the way down this page:

https://msfn.org/board/topic/97588-modern-mot … ussion/page/22/

He references a "Tenda TEL9901G" driver that sort of works if you un-remark portions of the .INF.

I looked through my driver library, and I found a newer Realtek Win98SE driver for the "SD-EXP24010" dated 10/30/2008, version 5.708.1030.2008 . It has RTL8168D listings (un-remarked).

Maybe that driver could work for you.

5.7blah is the main one I've tried.
I'll try the tenda, but I think that's likely to just be "leftovers in the inf".

Perhaps it's a red-herring, but I really suspect the linux driver gives a hint
https://github.com/mtorromeo/r8168/blob/master/src/r8168_n.c

1        _R("RTL8168CP/8111CP",
2        CFG_METHOD_7,
3        RxCfg_128_int_en | RxCfg_fet_multi_en | (RX_DMA_BURST << RxCfgDMAShift),
4        0xff7e1880,
5        Jumbo_Frame_6k),
6
7        _R("RTL8168CP/8111CP",
8        CFG_METHOD_8,
9        RxCfg_128_int_en | RxCfg_fet_multi_en | (RX_DMA_BURST << RxCfgDMAShift),
10        0xff7e1880,
11        Jumbo_Frame_6k),
12
13        _R("RTL8168D/8111D",
14        CFG_METHOD_9,
15        RxCfg_128_int_en | (RX_DMA_BURST << RxCfgDMAShift),
16        0xff7e1880,
17        Jumbo_Frame_9k),
18
19        _R("RTL8168D/8111D",
20        CFG_METHOD_10,
21        RxCfg_128_int_en | (RX_DMA_BURST << RxCfgDMAShift),
22        0xff7e1880,
23        Jumbo_Frame_9k),

RxCfg_fet_multi_en is in the C config but not the D
IF somehow this is the problem in the windows driver removing that bit from the init should in theory fix it.
I don't know what exactly this means at the code level.

The reason I suspect this could be it is simple : human error/laziness.

I suspect it is most likely the 9x driver code was never actually updated or tested.
There was really not much need in 2008 to do so.

Any idiot can add dev ids to an inf, but if the driver itself is sending incorrect init sequences for a prior standard, it'll never work.

There may be a way to fix it with an inf If the equivalent values align with registry keys by shifting the values down one key.

Eg a, b, c, d
Becomes a, c, d, null

A very quick and dirty glance at a decompile on https://dogbolt.org/

using Reko here

Shows the following things that look like they might do something.
NDIS.SYS!NdisInitUnicodeString(fp - 20, 0x0001B154);
NDIS.SYS!NdisInitUnicodeString(fp - 0x0C, 0x0001B17C);
NDIS.SYS!NdisMRegisterDevice(dwArg04, fp - 20, fp - 0x0C, fp - 0x0080, 171792, 171796);

NDIS.SYS!NdisInitializeWrapper(fp + 8, dwArg04, dwArg08, 0x00);

NDIS.SYS!NdisMRegisterMiniport(0x05, 0x00, 106630, 0x00, 0x00, 111892, 108500, 111120, 0x0001A5A0, 122216, 0x0001AB46, 121500, 0x00022E04, 110338, 107174, dwArg08, fp - 100, 0x60);

Of course, this is all barely above guessing.