> >> >>i'm using workgroup connection, netbeui, basic redirector...
> >> >>these settings work ( but require that all network files are located
> >> >>drive, floppy in my case ):
> >> >>config.sys
> >> >> device=protman.dos /i:A:\msnet
> >> >> device=workgroup.sys
> >> >>REM amd pcnet II pci adapter
> >> >> device=pcntnd.dos
> >> >I'm confused. Why would you want to do this? RAMdrives are empty
> >> >at boot, so loading device drivers from a RAMdrive would just require
> >> >you to copy the relevant files from another volume anyway. Plus you'd
> >> >need one of those command-line driver load utilities. Seems like a
> >> >lot of added complexity just to achieve the same exact result. What
> >> >are you really trying to do?
> >> >If you are looking for a way to save space on a boot floppy, you
> >> >might try compressing the drivers with a good exepacker like UPX.
> >> >This may or may not work, but it's worth a try.
> >> Actually this is standard procedure, but not with the network client
> >> he is using. NET BIND and NET INITATE will load most of the needed
> >> drivers (except IFSHELP) if the proper DOS client is used.
> >> The cannonical approach to using the RAMDRIVE is to extract the .cab
> >> or .zip file containing the bulk of the files needed for network
> >> connection and initial tasks to the RAMDRIVE, then to transfer control
> >> to a .bat file that was part of the archive (and is then on the
> >> RAMDRIVE). Normally this is done using a boot disk formatted /s on a
> >> Win98 machine so that larger HDDs will be recognized.
> >> The OP has not done his homework - he has not examined Bart's Boot
> >> Disks. He will not have the correct files nor the understanding to
> >> use them until he obtains, and uses or clones Modboot or something
> >> similar.
> >.sig in the body)
> >i am cloning/merging win98se bootdisk and workgroup connection
> Not everything that can be conceived will work. Sometimes it is
> possible to modify something that does work, but you have to start
> with what does work.
.sig in the body)
now there seems to be another viable solution in terms of 'afterboot' device
loaders (dynaload,device,ctload,devlod...) of which dynaload comes closest
(but still doesn't cut it) to load protman.dos (the actual problem)
when protman.dos is passed as an argument without its parameters to dynaload
it actually loads it (as seen by mem /c) but when /i:C:\MSNET (protocol.ini
directory) gets passed as well none of the loaders make it, all hang at
'Microsoft Protocol Manager Version 2.1' line
no problem with workgrp.sys and pcntnd.dos(ndis driver) except they require
protman.dos to be loaded beforehand :-(