Intel Ethernet Connection Driver for Windows 98SE

[dencorso]

Would there perchance be a PNP8fff in the registry, under /ENUM, at HKLM/, Dave?

If so, what does it contain?

 

I also have a feeling the installation of the MS Network Client 3.0 for DOS has something to do with it suddenly staring to work...

[jaclaz]

In the meantime, here is why the name E1000$ and how to configure further settings:

http://web.mit.edu/cron/documentation/dell-server-admin/en/IntelNIC/dos_odi.htm

though nothing about the "comma+PNPID" or "comma+Name"

 

I guess that something here:

ftp://ftp.microsoft.com./Services/whql/Tools/NSTL/000316/HCT/docs/

might be of use, but really cannot say if my guess can be accurate and/or if anything in it will be useful for what.

 

The RK98BOOK.CHM also contains possibly some related info:

ftp://ftp.microsoft.com/services/technet/samples/ps/win98/reskit/HELP/

but still nothing about that "comma" and added parameter.

 

jaclaz

Edited December 16, 2014 by jaclaz

[Dave-H]

Would there perchance be a PNP8fff in the registry, under /ENUM, at HKLM/, Dave?

If so, what does it contain?

 

I also have a feeling the installation of the MS Network Client 3.0 for DOS has something to do with it suddenly staring to work...

There is one entry in the registry here -

 

 

I doubt if installing the MS DOS Network Client would have had any effect, as I completely removed it and deleted all its folders and startup file entries before trying again with the Windows setup.

[Dave-H]

 

In the meantime, here is why the name E1000$ and how to configure further settings:

http://web.mit.edu/cron/documentation/dell-server-admin/en/IntelNIC/dos_odi.htm

though nothing about the "comma+PNPID" or "comma+Name"

 

Thanks, I looked at that document a while ago, and it was very useful to see detail about the PROTOCOL.INI options.

The only one I ended up using was specifying the slot.

 

I am assuming that when and if I enable the second onboard adapter, this will not be affected, in fact it seems to be seeing both of them anyway despite the fact that one of them is disabled with a hardware jumper at the moment!

 

 

I guess that something here:

ftp://ftp.microsoft.com./Services/whql/Tools/NSTL/000316/HCT/docs/

might be of use, but really cannot say if my guess can be accurate and/or if anything in it will be useful for what.

 

Goodness, I'll have a look at all that when I've got time!

 

The RK98BOOK.CHM also contains possibly some related info:

ftp://ftp.microsoft.com/services/technet/samples/ps/win98/reskit/HELP/

but still nothing about that "comma" and added parameter.

 

jaclaz

 

Ah, the old Windows 98 Resource Kit!

I've got a copy, but haven't had to look at it for ages.

I didn't think to look and see if there's anything about Windows networking with a DOS adapter driver, but I'm glad to say that it doesn't matter now anyway!

Edited December 17, 2014 by Dave-H

[jaclaz]

Well, that Registry entry seems to me (common sense only, not specific knowledge) more like a "two way link".

 

The entry is simmetrical to the entry in protocol.ini, meaning (maybe) that the same device Root/Net/0002 has two compatible ID's, and the entry in protocol.ini may mean that the same netcard can be called indifferently E1000$ or *PNP8fff.

 

Possibly you could try adding (of course only if you are after experimenting, and knowing that there is a risk to need to reinstall/restart) to add to both entries a comma and "MyNic", nothing should change.

Then try removing from both the *PNP8fff.

And finally try removing again the "MyNic" and see if only the "pair" of E1000$ is actually *needed*.

 

jaclaz

[Sfor]

To make such an experiment, it is enough to make a backup copy of the protocol.ini file.

 

For an example. I did install two ndis network adapters with different driver files. Then I did different bindigs in the Network Properties dialog. One network adapter is binded just to the TCP/IP the other got also NetBeui and Microsoft Networking. Then I did two versions of the protocol.ini files by removing all the bindings of one of the adapters in both copies. Of course both copies have different bindings missing.

 

Then I made two batch files to replace the protocol.ini file with one or the other copy. The batch files are renaming the network adapter DOS driver filenames, so just one is available at a time, as well.

 

Now I can switch the Windows to work with one adapter or the other, by running a batch file, without entering the Network Properties dialog. So it is enough to run a batch, then reboot. Or to call a batch in clean DOS, then net start, then run windows GUI.

 

What's more, both network adapter drivers are working with the same hardware. I had to hex edit the driver file and modify inf to do that. So, my Windows 98 has an ability to switch between two different network setup profiles, now.

Edited December 17, 2014 by Sfor

[jaclaz]

To make such an experiment, it is enough to make a backup copy of the protocol.ini file.

... and of the involved Registry key.

 

jaclaz

[Dave-H]

I have ordered another (eSATA) PCI card to replace my now redundant plugin Ethernet card, but it won't arrive until the first week of January, and I don't really want to open up the machine and start experimenting again until I can do all that in one go.

I hope that enabling the second on-board Ethernet adapter won't cause any problems, as I'd quite like to use that for a direct connection to my netbook for transferring files.

As I said, the second adapter is disabled at the moment by a hardware jumper on the motherboard, so I am a bit surprised that the DOS driver is apparently seeing it at all!

[submix8c]

Dunno if this will help but it *implies* that the PNP8FFF entry *could* be anything "available".

http://pranaykr.blogspot.com/2005/02/lesson-data-link-and-physical-layers.html

Google-foo says these are the "ranges" usable: PNP8000-PNP8FFF

And going back to the Documentation it says to provide *multiple* entries in PROTOCOL.INI.

http://web.mit.edu/cron/documentation/dell-server-admin/en/IntelNIC/dos_odi.htm

(above is just an additional link to the previous ones)

 

HTH - and definitely back up the INI and REG before fiddling. BTW, is there more than one REG entry? *Theoretically" creating another entry (based upon above) and modifying the INI *should* work.

Edited December 19, 2014 by submix8c

[jaclaz]

And going back to the Documentation it says to provide *multiple* entries in PROTOCOL.INI.

http://web.mit.edu/cron/documentation/dell-server-admin/en/IntelNIC/dos_odi.htm

(above is just an additional link to the previous ones)

BUT it does NOT say ANYTHING about multiple values in "netcards =" (as a matter of fact it doesn't even mention "netcards").

 

However, here there is another example of having a PNP id:

http://download.modem-help.co.uk/mfcs-J/JAHT/driver/jn110rw-driver.zip.php?showFile=JN-110RW%2FBOOTROM%2FSUBOOT%2FPROTOCOL.INI

And an even more interesting thing:

http://ftp.lakesoft.net/ftp/drivers/nic/davicom%20lan/davicom9102/bootrom/ntsrv/win95/protocol.ini

a direct reference to PCI VEN and DEV

 

[data]

version=v4.00.950

netcards=DM9PCI$,PCI\VEN_1282&DEV_9102

 

Which makes me think that my previous guess was completely wrong , and the value is a sort of "binding" between the driver instance and corresponding piece of hardware, that at this point can seemingly be referred to by Hardware ID, PNP ID or some sort of "friendly name" as the "ATHEROSL2" Sfor has,

 

Unrelated, but interesting:

ftp://ftp.microsoft.com/MISC1/BUSSYS/WINNT/KB/Q185/9/16.TXT

 

jaclaz

[Drugwash]

As I said, the second adapter is disabled at the moment by a hardware jumper on the motherboard, so I am a bit surprised that the DOS driver is apparently seeing it at all!

You said the on-board adapter is dual; maybe the driver is detecting a secondary adapter that actually belongs to the on-board LAN chip not to the disabled one in the PCI slot. Unfortunately I have no idea how to distinguish between the two, if at all possible with the DOS driver.

Anyway this is easy to check after you physically pull the PCI adapter out.

[Dave-H]

I'd already tried that as a test a while ago when I was still trying to get the DOS driver working.

I pulled out the plugin Ethernet card, and it still saw two adapters!

[buyerninety]

submix8c said:

"Dunno if this will help but it *implies* that the PNP8FFF entry *could* be anything "available".

http://pranaykr.blogspot.com/2005/02/lesson-data-link-and-physical-layers.html"

 

I wonder if we're misreading that webpage - the author of that webpage seems

to be listing the text as it lays (is seen) of his Win98 registry. If you look at the

1st occurrence of PNP in that webpage, it does seem at first as if it were a

listing of the PROTOCOL.INI text, but if you scroll up and down it becomes

evident that that text is actually a representation of the Win98 registry text.

Also, the 2nd occurrence of the PNP has this sentence immediately preceding it;

"An Advanced tab is available for network adapter settings which are set in the

Registry and the PROTOCOL.INI "

" PROTOCOL.INI
[EXP16$]
DriverName=EXP16$
irq=5
ioaddress=0x300

[data]
version=v4.00.170
netcard=EXP16$,*PNP812D "

Therefore, it could be that the above text is in fact meant to be (read as) a

representation of Win98 registry text, rather than PROTOCOL.INI text - (it's

open to misinterpretation).

 

===================

 

I'm not aware what program or process dropped that *PNP8FFF into Dave-H's

protocol.ini .

PNP ID's in that format do get written into the registry, from a network adapters

INF file, as explained e.g. here; www2.gol.com/users/pbw/filelib/BATCH98.DOC

 

===================

 

Another thing - I notice in the "*multiple* entries in PROTOCOL.INI" webpage

http://web.mit.edu/cron/documentation/dell-server-admin/en/IntelNIC/dos_odi.htm

that submix8c mentioned, that it says to use E1002$ , E1003$ , etc. for multiple

instances of the E1000$ Drivername (in protocol.ini).

If it occurs that multiple instances are required, and that doesn't seem to work,

try using instead e.g., E10002$ .The reason is that that appears to be the

format of the usage that other manufacturers Drivernames use, and also

I see when I look inside file 'E1000.DOS', this error message;

"PROTOCOL.INI does not have a DRIVERNAME = E1000x entry.
The driver looks for DRIVERNAME based on its load order in CONFIG.SYS,
the second E1000 driver loaded uses E10002, the third uses E10003, etc."
 

[LoneCrusader]

for what it's worth there's e1000nt5.sys from 6/22/2004 ver. 8.0.57 that according to wdmcheck has one missing function.  If I remember correctly it was for a dual port but with an earlier chip.

 

This is a possibility that should not be quickly dismissed though. If the driver farfigs11 mentions only lacks one WDM function under 98SE, then there is a chance that it could be made to load with WDMSTUB or a more advanced approach such as rloew's WDMEX. The real question is what other dependencies might that specific file have, and is it deeply intertwined with some other part of the Windows driver package that requires NT; or, will it "just work" as a substitute for the 9x file when placed with the rest of the last driver package for 9x provided the missing function is satisfied.

Since the thread is still going, I thought I would add a bit more information on this for the record.

I downloaded and examined the file referenced by farfigs11. I have no means of testing it, but I assume the missing function he is referring to is NdisMQueryAdapterInstanceName. Everything else seems to be satisfied; although still no guarantee it would work under 9x, even if this was stubbed or satisfied.

[Dave-H]

Happy New Year everybody!

Just reporting back in to say that my eSATA PCI card arrived a bit earlier than I expected, and I've now removed the plug-in Ethernet card and replaced it with the new card.
Amazingly, it actually has Windows 98 drivers!

http://www.msfn.org/board/topic/173268-esata-card-drivers-for-windows-98/

I also re-enabled the second on-board Ethernet controller.
No real problems, the readout on the startup of Windows 98 looks exactly the same as before, which confirms that the Windows 98 system was seeing the second on-board card even while it was supposedly disabled using a hardware jumper.

I don't actually need the second on-board card working in Windows 98 so I haven't looked into trying to get it working alongside the first one.
I'm just grateful that we got the first one working!

Edited January 3, 2015 by Dave-H