Some notes on platform-independence and Windows:

  First, Windows has some definite incompatibilities (partially through
   different design concepts, and partially through design flaws) with
   Unix.

  Secondly, Unix is very different from, say, MacOS.

  Visual BASIC is written specifically for Windows; you can see this in
   its API.

  While the progession of VB to a Win32 system has cleared up a LOT of
   these problems, since memory management is significantly more transparent
   now, it doesn't take care of everything.

  Making VB friendly to Windows NT has helped a lot, since NT tends to be
   more abstract; after all, it runs on at least two vastly different
   architectures. This is to our benefit, although even WinNT does some
   stuff a little less intensely than Unix (for example, NTFS is not
   case sensitive, uses drive letters, etc...)

  There are a few notable areas where we'll have to fight to keep things
   compatible. They are:

     - File system compatibility and file/device i/o.
     - GUI interface.
     - ActiveX.

  Just about everything else can be transparently emulated, if nothing else.


FILE SYSTEM AND FILE I/O:

  The most notable variation between Microsoft OSes and Unix is how they
   handle the file system. A Mac handles its file system in a third
   incompatible way. What it comes down to is a need for abstraction in
   the API.

  Of course, that sounds good on paper.

  Java has it easy, since Sun could warn their programmers not to embed
   filenames right from the start; they supply an interface to abstract
   filename entry and output, so it works the same on any interface.

  Visual Basic has no such interface. Therefore there is a ton of legacy
   code that not only hardcodes filenames, and path characters, but also
   expects to be able to find those path characters and filenames in
   return values.

  If nothing else, all that legacy code IS going to expect a drive letter...

  So here's what I think: First, the programmer should be encouraged,
   whether using vbSlacker or regular ol' VB or VisualAge for BASIC, or
   anything else, to always write code in a platform independent fashion.
   Never hardcode filenames, paths, or even make assumptions that drive
   letters are available. File selection should be abstracted into file
   dialogs, or be user-specified at all times through input or config
   files or whatnot. Things like curdir$() and curdrive$() should be
   avoided like the plague, as you should never concern yourself with
   the current working directory.

  Failing that...

  APIs that accept filenames (KILL, OPEN, NAME, etc...) will always accept
   both Windows-like filenames and unix-like filenames. On Unix-like and
   Macintosh systems, the drive letter (if specified) must be "C:" or a
   runtime error is thrown (this is okay for legacy code...after all, on
   Windows, if I don't have a "D:" and try to access it, you can expect an
   error. Therefore Linux and friends have, as far as the vbSlacker
   process is concerned, only a "C:" drive. There are no "A:" and "B:"\ 
   drives, which is still plausible under Windows. The "\" characters in a
   path are converted to "/".

  If the "ignore filename case" runtime option is NOT set, case will still
   be significant. If set, anything that must access files will access the
   file with the exact specified case, and failing that, will access the first
   to match an case-insensitive search. This option is not recommended unless
   your code is REALLY legacy, but it can be helpful for programs that make
   poor use of the File I/O and File System APIs. This option should not be
   available to a Win32 or OS/2 system, since they are already
   case-insensitive.

  Note the dangers of this, though: If two files match a criteria, the first
   one is selected, even if it is not the intended file. The solution to this
   is to specify the correct case from the beginning, since the exact match
   is always selected over the case-insensitive match. However, if you could
   always do that, why would you use this option in the first place?

  Furthermore, since directories also are checked for insensitive matches,
   you could end up traversing a completely unexpected subtree on the
   file system.

  Files you create (with MKDIR and OPEN, etc...) are also matched first. This
   could lead to unexpected errors or worse, data overwriting.  Still, it was
   necessary to do this, so you can OPEN a file as "C:\myfile" when you
   create it, and still get the same file when you use "C:\MYFILE" later. Note
   that if there is no match for "myfile" when created, it'll be created in
   the specified case.

  So use at your own risk. Generally, it WON'T cause problems, and will help
   port legacy code. But the risk is there.

  Other file stuff:

  Things that expect various file attributes are treated differently:

    (On win32 and OS/2, these are just checked against the various flags
     inherent in the file system. Other platform differences are noted
     below.)

    vbNormal    : same as always.
    vbReadOnly  : The file is checked to see if the process does NOT
                   have permission to write to the file.
    vbHidden    : On unix-based systems, files starting with '.' are
                   considered to be "hidden." On MacOS, no files ever
                   match this attribute, since there is no such thing
                   as a "hidden" file on MacOS. !!! is this wrong? 
    vbSystem    : ignored. There is no such thing as a "system" file.
    vbVolume    : ignored. There is no such thing as a "volume" file.
    vbDirectory : same as always.

  Besides that, the only thing we need worry about is return values. For
   example, a BASIC program that parses a directory is going to expect DIR$()
   to return a value like "D:\DIR1\DIR2\FEH.TXT", which is no good at all on
   Unix.

  So, we set up another runtime option: Windows file compatibility.
   This allows for either a "native feel", where a programmer may choose
   to hardcode platform-specific details, or legacy code may be up and running
   that much quicker. In "Windows filesystem compatibility" mode, CURDRIVE$()
   always returns "C:". File dialog boxes are roughly Windows-like, but
   specify only a "C:" to click through.

  Therefore, for any platform vbSlacker runs on, it needs to supply a few
   functions:

     __convertPathWinToLocal(p) : Convert a string (which may or may not be
      a windows compatible path) to a local path format.  Under unix, this
      means losing the drive letter (and throwing an error if the letter is
      anything other than C:), and converting '\\' characters in the path to
      '/'. The return value should be a newly allocated, garbage-collectable
      asciz string. (p) is a path in an asciz string.

     __convertPathLocalToWin(p) : Do the opposite of __convertPathWinToLocal().
      Under unix, "/mydir1/mydir2/filename.txt" becomes
      "C:\mydir1\mydir2\filename.txt" ... This is so return values can be
      in a format legacy code expects, if the option is enabled.

     __getCurrentDriveLetter(void) : Return a byte of the current working
      drive letter. Under Unix and OSes without a concept of drive letters,
      this always returns ('C')...under OS/2 and Windows, we have to make
      calls to platform-specific APIs for this information...


!!! MORE TO COME!

/* end of windows_compatibility.txt ... */

