Table of contents
The Microsoft utility regini.exe is no longer among the "redistributables" shipped with Windows NT. Our Windows NT driver Version 1.8 comes with two alternative methods to get the necessary information into the Registry: a Perl script and a C program.
I can't open the Secio device driver.
Is it loaded and running? Check in the Devices applet in Control Panel. If the entry doesn't show up there, is the entry in the Registry correct? It is often necessary to reboot Windows NT after changing the Registry entry.
I get unreal, drifting, counter values.
The device driver is probably in emulation mode. In the Registry, make sure the EmulateHardware key has a value of zero.
What is EmulateHardware, anyway.
It is a mode that allows some rudimentary application software development on a machine without a physical SEC board. Set the EmulateHardware flag in the Registry to 1 and reboot Windows NT.
Is there any hope for my old 16-bit Windows apps on NT?
Why yes, there is. We provide a little Virtual Device Driver (Vdd) that traps the I/O port accesses and redirects them to the Secio device driver.
Is there any hope for my old 16-bit DOS apps on NT?
Same answer.
Will the NT apps I am developing work under Windows 95?
No, they won't, unless you do some planning beforehand. The I/O systems of Windows NT and Windows 95 are quite different. But FCS has several ways to help you plan a good portable application.
Our Windows 95 VxD mimics the Windows NT driver fairly well, so most DeviceIoControll() calls that work in one work in the other.
Our DLL series helps simplify the interface to both drivers.
Our object-oriented programming examples offer some ideas on how to hide platform differences.
How does one open the Secio device driver under Posix?
Good question. Anyone speak Posix out there?
Attempting to unload the Secio device driver crashes NT.
Yes, it does crash Version 1.4. The bug has been fixed in Version 1.8. The driver may now be stopped with the Devices applet or with "net stop", and restarted successfully. Note, however, that if the Legacy Vdd is running above the driver, the OS may not be happy about yanking the driver out from under it.
For those wishing to back-port Windows NT applications to Windows 95, FCS has a VxD that presents an almost identical API. The app opens the driver with a CreateFile() call, then issues DeviceIoControl() calls to communicate with the SEC. The driver name passed to the CreateFile() is slightly different. Block reads/writes to the ROM/RAM are not implemented.
My compiler doesn't support direct port I/O.
We resorted to inline assembly language code in our Delphi and C++ examples. That's not very portable code, so it's best to encapsulate it in the lowest level routines. At one point our C++ compiler even became balky about inline assembly code, so we made a little library module with only two tiny functions: byte port in, and byte port out.
How about a 32-bit DLL for Windows 95?
You asked for it, and now it is available (November 1997). It's a natural for you Visual Basic and Delphi developers. And for everyone, it can ease the pain of making applications that work on both Windows NT and Windows 95. See the DLL page. Those of you who have used the 1994 FCS 16-bit DLL/VBX for Windows 3.1 will feel right at home.
What is the standard setting for the I/O port range?
All of the original 16-bit example programs published by FCS used a base port addres of 330 hex. That is still the default. Some newer machines may have a conflict with a SCSI controller or a Plug 'n Play sound board at that address. The second choice for those machines is 364 hex.