On 20 Jan 2021 at 0:42, andrea...@tiscali.it wrote: > Now I am trying to load a diver for a toshiba satellite with > Marvell Yukon eth.card: I found the driver (yukodi driver) > and it would seem to work, and system says it loaded > odi packet driver and so on, but neither Arachne no Link go up on > internet. I have a wattcp.cfg (My_ip = dhcp), as usual, > but they fail.
...oh wait. Let's speak ugly details. fetpkt is likely a native packet driver with CRYNWR API. That's what many DOS TCP/IP networking apps are using. (Pretty much anything outside Novell and Microsoft.) b44.odi is a Novell ODI driver = does not provide the CRYNWR API itself. But if you say that you're using b44.odi, you probably also have the odipkt.com. Now you say that the driver Yukodi does not work for you. Looks like another ODI driver. Hmm... if Arachne and others look all happy, does that mean that odipkt.com is loaded as well? Also, AFAICT the Yukon NIC is a PCI device, so you should not be required to tell the driver about any particular hardware resources such as base IO address and IRQ (and possibly get them wrong). At my workplace, I've been using the Microsoft Network client for DOS for ages, even on relatively modern hardware. And for most networking cards, the vendors have kept providing updated drivers for the Microsoft stack = those with the .DOS suffix. And, I can see traces of information that there used to be a shim driver called the dis_pkt.dos , to provide the CRYNWR packet driver interface on top of a Microsoft-style networking driver stack. Analogous to your odipkt.com which is Novell-flavoured. Unfortunately I cannot provide you with a complete boilerplate script and config file for the whole microsoft stack. I've had experience with the "Hiren's boot CD" software package where the loading of the .DOS drivers is kind of automated... Other than that, this is DOS... same old, same old. No memory protection, drivers must load resident in a couple kilobytes under 1 MB... namely the network drivers typically work but sometimes don't... You may get different results based on what DOS version you use, what EMS/XMS manager and its options, what CPU you are running on, and possibly what phase of the moon it is... I have recent unhappy experiences with DOS networking and other stuff (general application compatibility) in virtual environments (QEMU). This is computer archaeology. Trying to make your super-ancient OS run on modern PC hardware. It's a miracle that it manages to boot at all. I'm not surprised that no serious effort is wasted on trying to create modern apps for this programming environment, such as a modern web browser - from a programmer's perspective this is a ridiculous proposal. Frank
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
