Thank you for your interest in SysInfo
======================================

The documentation for SysInfo is in the file SYSINFO.TXT. This is a standard
text file. It is much prettier than the text file with version 1.0, mostly
because the tool that converts the original document in TeX to an ASCII file
was improved.

As the manual in SYSINFO explains, this is really a tool (or library) for
programmers. The user interface of the example program SHOWINFO.C is... well,
lacking. Still, I use SHOWINFO every now and then (mostly on new computers, or
on computers brought in for repair), because I have come to trust it.


New in this release (version 1.1)
=================================

o  Quite a few bug fixes (unsuspectibly). Most had to do with the mouse,
   modems or another apparatus that was branched to the communications port.
   The device stopped working after loading SYSINFO.EXE. I have corrected the
   checks for RS232 ports and the mouse to be more carefull not to break port
   settings and not to upset other programs that monitor the ports.

o  Incidentally, I also found a bug in the Expanded Memory check. It crashed
   if no expanded memory emulator was present. I was surprised that I had been
   caught by such a silly (and avoidable) error. But I was even more surprised
   that I had not received a bug report for it. So either almost everybody is
   running EMM386.EXE today, or those of you you tried version 1.0 and crashed
   the machine just threw SysInfo in the recycle bin and did not bother to
   write.

   If that happened to you, please accept my apologies. Detection routines
   are difficult to write in a way that they work on every posibble
   configuration. I write the code carefully and test it routinely on half
   a dozen computers that I have access to (and they all have different
   configurations). I also test it on other computers that come by. And I
   test *every* routine. That is a lot of work. If you just look at the list
   of video cards that can be detected, you will get the idea. Yes, I do have
   a machine with an old IBM MDA, and a CGA (although the monitor broke down
   recently), and the old Hercules card, and an EGA, and MCGA (with monochrome
   and colour monitors), and...

   If you look at it from that point of view, sending me an e-mail because you
   found an error is really not that much trouble in comparison with the
   efforts I went through to create a free utility. And although I cannot
   guarantee that I can fix the error you found, I am *not* going to ignore
   bug reports. I use SysInfo for my own (commercial) programs. If you find a
   bug in SysInfo, you have in effect also found a bug in many of my other
   programs. So I *do* care about errors and incompatibilities that you may
   find.

o  The mouse types have been expanded. The IBM PS/2 style mouse is found (with
   and without driver). There is also more information on the mouse driver.

o  SysInfo now detects the FPU in more detail. SysInfo includes a check for the
   infamous FDIV bug that plagued the FPU inside the earlier (but widespread!)
   Pentium chips.

o  The Weitek Abacus co-processor is now also detected. The Weitek co-processor
   can only be used in 32-bit protected mode or in Virtual 86 mode via an
   EMM emulator. EMM386 is such an emulator. SysInfo queries EMM386 for the
   presence of the Weitek processor, so you need to have it installed to detect
   the Weitek co-processor.

o  PCMCIA slots are now detected (the version of the interface and the number
   of sockets).

o  The flags-parameter for the DRIVE_INFO structure is now set under
   Windows 95. You can use it to detect long filename support.

o  Detection for EPP printer ports has been disabled. The DOS box of Windows 95
   crashed (on a bizarre printer port that I have in one of my systems) if I
   called this function repeatedly.

o  si_fullpath now uses the "method" parameter. With this, you can convert
   from long filenames to short filenames and vice versa. Under Windows 95,
   the "method" maps directly to one of the "long filename" functions; under
   DOS (or in Windows 95 without the VFAT virtual device driver), si_fullpath
   does some low level reading of the directory structure to resolve long
   filenames. (Note: this is independent of the "flags" parameter in the
   DRIVE_INFO structure; the disk or diskette may have long filenames stored
   in the directory structure while the operating system that is running
   does not support the long filename functions).


Problems
========

o  The return value of si_mouse is incompatible with previous versions;
   the constant MOUSE_MSSER has become 2 (it was 1) and the constant
   MOUSE_UNKNOWN now is 6 (it was 2). If your program uses si_mouse, you
   *must* recompile to get correct results.

o  The constant SI_OS (Operating System) in SYSINFO.H is gone. It was never
   documented (apart from a note in the README.TXT of version 1.0) and it was
   never implemented. The value of the constant (15) is now taken by SI_PCMCIA.

   The operating system is currently not detected, and I don't know if it is
   worth detecting it. The main reason for wanting to know the operating system
   is because some software may not run (correctly) in a DOS box under one
   particular operating system. But I would rather want to detect the source of
   the problem: why does such a program not run correctly.

   Sometimes, a piece of software simply does not run in V86 mode (so not even
   in DOS with EMM386 installed). This is usually caused because the program
   was compiled with an older compiler that simulated interrupt calling in a
   way that looked sensible before the existence of the 80386, but which V86
   monitors are unable to handle (a V86 monitor is a program like QEMM or
   EMM386).

   Sometimes, there is a speed or timing problem, or a problem in accessing the
   hardware directly. But I would rather have programs test if an environment
   is fast enough, rather than simply stating that it may not run correctly
   under operating system X. For the "direct hardware access" issue, I have
   thought about a function that returns you whether a port address is
   virtualized (in V86 mode). If a port is virtualized, access to it will be
   slower, and writing to the port may not do what you intended. The problem
   in the last sentence is the word "may". It is possible that the operating
   system passes all writes to a virtualized port through to the port.
   Microsoft Windows 3.1 does this a lot. But again, knowing the particular
   operating system and its version is not a solution. The user may have
   installed a driver that virtualizes a port that the default setup did not
   virtualize.

   Finally, there are some utilities that absolutely *must* run in the
   foreground (no multitasking). I know of no good way to detect multi-tasking
   in general, so the only viable option may be to detect the operating systems
   that may give trouble (Windows 3.x, Windows95, OS/2, DesqView, perhaps some
   flavour of UNIX that emulates a DOS machine).

   Tell me what you think. Do your programs need to know the operating system?
   Is there a better alternative?


Contacting the author
=====================

If SysInfo does not do what you need, e.g. you wish it would detect the network
user name of the person that is currently logged in, post a request to me.

If you find bugs in SysInfo, or if it crashes on your computer, or of it gives
a false positive, please also contact me. Of course, in case of a hang-up, I
would like to know what particular routine hangs. In that case, try to run
SysInfo in diagnostic mode and make a hardcopy ("PrintScreen") of it. Also, try
to run MSD (Microsoft Diagnostics) or a similar program to see what they say
about the particular component on which SysInfo chokes.

ITB CompuPhase
Thiadmer Riemersma
Compuserve: 100115,2074
e-mail: thiadmer@compuphase.com
WWW: http://www.compuphase.com/daemon.htm

