Sfor

Thank you, very much. I was able to turn the "files with unknown extension" search option on. It was a bit difficult to find it, because the Microsoft article is in English, while my Windows is in Polish. After quite a while I was able to overcome the translation related difficulties. They hid this option well, indeed.

Well. I tried to find log files with a certain keyword in them, but the Windows XP just ignored the files with .B and .BLG extensions. When I did the same in Windows 2000 the files were located, correctly. So, there is quite a difference between the Windows 2000 and XP Find Files function. Is it possible to affect the way Windows XP searches the files? Or, should I rather use a different file search tool?

Well, it works correctly, now. The reason is simple. The files on the server had read only attribute set, while the local copies did not. That's why the symbolic links were working differently, depending on where they were pointing to.

You are right. I did use the Link Shell Extension and the driver mentioned there. There are many pages related to this topic and many of them are not quite precise. What I found so far: - The symbolic links are working in general. The only requirement is the driver and NTFS partition. However it is possible to link to files on a server without driver and without NTFS, as well. For an example I did link to a Windows 2000 share set on FAT32 partition. - the application I'm toying with accepts the symbolic link for one of the files. The file is accessed correctly, as far as I can see. However two other data files are as good as missing. It could be related somehow to the file open procedure. The problematic files are opening correctly in Explorer, but the application does not seem to be able to open them. However, everything works fine, if the symbolic links are pointing to the files located on the same system (other partition). So, the symbolic links to networked shares do not work as intended in some cases.

Well. My investigation shows the Symbolic Links with ability to link through networked systems were added in Windows Vista. Also, it looks like there is a file system filter driver able to add such a feature to Windows XP. I'm trying to speed up network application booting by moving executables to local HDD. To do that I need to copy a directory of the application from the server to local HDD with an exception of a few data files. Some data files are accessed within the same folder the EXE file was run from. So, in order to make this idea a reality it is necesary to make symbolic links on workstations, so the application will seek the databases on local HDD, but the data will be kept on the server. - the hard links within a single NTFS partition will not solve the problem - the directory junction feature will not do the trick - the symbolic links from Windows Vista (and newer) should be able to solve the problem - perhaps there is some other solution I'm not aware of. For an example there was an APPEND command in the DOS. In any case the Path enviroment string does not do the trick.

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.

Well. Testing the DOS driver with TCP/IP protocol is simply forcing things. It should be faster and simpler to test just the NetBeui with Microsoft Networking. This will answer the question, if "the DOS driver is actually working in DOS". What's more important, all the necesary elements are available, and were linked together, already.

Well. The task is to test the drivers able to work with Windows 98, right? I doubt Windows 98 GUI can work with DOS based TCP/IP driver. So what's the point in testing it?

I would not recommend to test the DOS drivers with TCP/IP. The reason is quite simple, DOS drivers do not support TCP/IP. On the other hand, the NetBeui should work along with Microsoft Networking Client.

It looks like all the items are there, but there is some problem with the link. In case of my system, there are bindings in the network applet list. I did bind the NDIS driver with TCP/IP and NetBeui transport protocols. I binded them with Microsoft Networking services. The interesting part is the TCP/IP binding does not appear in the PROTOCOL.INI. All the TCP/IP is done by the GUI part of the Windows, while the DOS part does just the NetBeui. Also, the network performance is affected by the processor temperature. It looks like the DOS portions of this network system is much more dependant on the CPU, then the 32bit counterparts.

The NDIS network adapter will not appear by itself. One has to install it the way I showed quite a few posts ago.

No, it does not. There is just the NDIS network adapter. When the DOS driver is not present, the according NDIS network adapter entry has a ! mark on it. I found the Windows 98 boots quicker without the network adapters. So, I made a DOS boot menu with option to boot faster without the network. If the net start is not run in autoexec.bat, the windows starts quicker, but network does not work.

What can I say. It simply works. Not in the DOS, of course. Somehow GUI network components are able to use the DOS drivers. But for it to work correctly there has to be a link established between the Windows components and DOS drivers (I believe NDIS.VXD does it). In my case the bindings made with GUI were transfered correctly to the protocol.ini. The example I provided was made by Windows GUI network setup functions. Long ago, when I was still playing with 10Mbit ISA network adapters, all of them had Windows 95 dedicated driver sets with both 16 and 32bit drivers in them. It was possible to select the version to be used. With 16bit drivers I was possible to skip loading GUI and use NetBeui protocol for networking in DOS. But since the PCI came in, all the driver packages were provided with just 32bit versions.

It looks like you have some problems with bindings in the PROTOCOL.INI file. Here is mine for the reference. [ndishlp$]DriverName=ndishlp$Bindings=ATL2$[protman$]DriverName=protman$priority=ndishlp$[data]version=v4.10.2222netcards=ATL2$,ATHEROSL2[NETBEUI$]sessions=10ncbs=12DriverName=NETBEUI$Lanabase=6Bindings=ATL2$[ATL2$]DriverName=ATL2$

Well. I did use the Microsoft Networking in plain DOS, before. While using 16bit DOS drivers it was possible to boot just to the DOS, run the net start, and there was the DOS networking without the GUI. It worked with Windows 95, as far as I remember.

I just remembered something. Windows 98 does driver file copying every time something is changed in the protocols or bindings in the network settings dialog. So, the drivers do not have to be copied during network adaprter adding, sice they will be copied after bindings with network protocols are made.

No, I do not. But Windows loads it by itself, anyways.

There is nothing network related in my Config.sys file. Also. It should be possible to boot just to the DOS prompt, then to start the DOS drivers with net start command. By doing so it should be possible to see all DOS driver related error messages.

There is a significant difference here: devdir=1:E1000.dosdevdir=?:l2.dosThe both INF files seem to have a different syntax. I see no meaning in the [PCI] section, as it was not defined earlier. Are you sure it is a proper Ndis2 driver? In my case the package contains 4 files: ATHEROSL2.NIF l2.dos OEMSETUP.INF PROTOCOL.INI

Here is how my .INF file looks like: ;ATHEROSL2 OEMSETUP.INF File:[netcard]ATHEROSL2="Atheros L2 Fast Ethernet Adapter",000,ndis,ethernet,real,ATHEROSL2,ATHEROSL2_nif[ATHEROSL2]devdir=?:l2.dosdevice=l2.dos,@devdir\l2.dos[ATHEROSL2_nif]drivername=ATL2$param=ETHERID,"Node Address",chars,13,"@000000000000",0x02

In case of my Eee PC device manager there is a disabled entry with "PCI Ethernet Controller" that should stay disabled. This one is the detected by Windows PCI device. It is not used, since the NDIS2 driver is used instead. The NDIS2 driver entry says "Atheros L2 Fast Ethernet Adapter".

Well, the driver files for a Ndis2 network adapter are mostly in DOS mode. The Device Manager can only show NDIS.VXD, as there are no more related 32 bit files. In order to check if the 16 bit DOS mode drivers are present it is necesary to use "mem /c /p" command. There should be PROTMAN, NDISHLP and Ndis2 driver modules on the list. If the binding went well, there should be an an information in the properties of the network adapter in device manager. Something like "this device is working correctly". If some device drivers reported an error condition, an exclamation mark should appear and a message saying "it is not possible to load device driver" (or something like that). That said, everything will work like I said if the bindings in the protocol.ini file are correct. If the bindings were not made properly, and there are no drivers listed there, they will not be loaded, and there will be no error message in the device manager. Since the NET start command was missing, it is possible something went wrong with the protocol.ini file parsing. Also, all the network adapter settings are made through the protocol.ini file entries. It could be a MAC setting, hardware address, IRQ or link speed.

First of all there is no need to edit the autoexec.bat or config.sys files, when adding a ndis 16bit network driver in the Windows 98 OS. Windows will do all by itself. But to be more specific only autoexec.bat will get added a "C:\WINDOWS\net start" line. The rest will do the net command. The way to get a NDIS 16bit driver added is: (I will have to translate from Polish Windows 98 to English, so there could be some differences. Well, it should be something like manually adding a network adapter.) 1) Open network neigbourhood parameters/settings? 2) Click Add 3) Select Nework Adapter/Card and click Add 4) In the first list (Manufacturer) it should be a second line from top, I think (recognized driver or something), in second list (Network Adapters) there should be just two entries a Ndis2 driver related entry and ODI related entry. Select the one for NDIS and click "From Disk" button. 5) Now is the time to show where is OEMSETUP.INF file located. 6) Then Windows should copy the drivers then modify it's config files by itself. All the network drivers are loaded with the "C:\WINDOWS\net start" from autoexec.bat. The protman and other Ndis2 drivers will be loaded by the net command according to the PROTMAN.INI file bindings.

I bought a VERITAS Backup Exec CD on Ebay. It was distributed by Dell, apparently. There are Seagate Backup Exec for Windows 95/98/NT 4.01b (SRS) and Veritas Backup Exec for Windows 2000 4.4 (NDR) on the CD. I did install the Veritas Backup Exec from the disk, but the Windows 2000 died after the reboot. --------------------------------------------------------- After restoring the system from a copy, I was able to install the software. Everything seems to be working fine, now. I did experiment with other tape software and UURollup on the deceased system copy. So, there could be some sort of a conflict. In any case, it is wise to be careful, when installing Veritas Backup Exec, apparently.

I did some research. It appears, the Veritas sold Backup Exec Desktop to Stompsoft, which was renamed to Backup My PC. With Backup My PC 5.0 the compatibility with backups made by older versions was broken. So, the best choice would be some version of Veritas Backup Exec Desktop, or Stomp Backup My PC version below 5.0. Now the biggest problem is, both Veritas and Stomp are gone. How one can obtain this particular software?