windows_compatibility.txt
1
2
3
4
5
6
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.
7
Secondly, Unix is very different from, say, MacOS.
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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
35
handle the file system. A Mac handles its file system in a third
36
37
38
39
40
incompatible way. What it comes down to is a need for abstraction in
the API.
Of course, that sounds good on paper.
41
Java has it easy, since Sun could warn their programmers not to embed
42
43
44
45
46
47
48
49
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.
50
If nothing else, all that legacy code IS going to expect a drive letter...
51
52
53
54
55
56
57
58
59
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
60
the current working directory.
61
62
63
64
Failing that...
APIs that accept filenames (KILL, OPEN, NAME, etc...) will always accept
65
66
67
68
69
70
71
72
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 "/".
73
74
75
76
77
78
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
79
80
81
82
83
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
84
one is selected, even if it is not the intended file. The solution to this
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
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:
104
105
106
Things that expect various file attributes are treated differently:
107
108
109
110
(On win32 and OS/2, these are just checked against the various flags
inherent in the file system. Other platform differences are noted
below.)
111
vbNormal : same as always.
112
113
vbReadOnly : The file is checked to see if the process does NOT
have permission to write to the file.
114
115
116
117
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?
118
119
120
121
122
123
124
125
126
127
128
129
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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
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...
153
154
155
156
157
!!! MORE TO COME!
/* end of windows_compatibility.txt ... */