|
|
1.1 root 1: Porting dmsdos to Win32
2: -----------------------
3:
4: If you want to use dmsdos under a 32 bit Microsoft Windows system such as
5: Win95/98 or Win NT 4.0 there are two possibilities: try it at user level
6: (easy) or at driver level (difficult but more interesting).
7:
8: Don't try a 16 bit environment. You won't get it work as dmsdos needs more
9: than 1MB of temporary memory. Buy the appropriate MS-DOS or Stacker version
10: instead. They're also faster because they are said to contain hand-optimized
11: assembler code.
12:
13: At least, there's no Win NT version of Doublespace, Drivespace or Stacker.
14: This makes dmsdos somewhat interesting for Win32 :)
15:
16: Well you can also try a 32 bit extended Dos environment such as DJGPP.
17:
18:
19: A. User Level
20: -------------
21:
22: I tried, and I found Win32 programming is not fun. At least if you are
23: used to programming in a Unix environment.
24:
25: It _should_ be easy to compile libdmsdos and, for example, dcread under any
26: 32 bit environment. Well, I tried Win NT 4.0 with Cygnus' Win32 B19 version
27: of gcc, but almost nothing worked. The configure script, which runs under
28: pure bash, didn't run with the bash found in that package. So what, I then
29: configured dmsdos under Linux and copied the config files. With a lot of
30: hacking, I finally managed to compile libdmsdos, but it was of no use.
31: Whatever I did, when linking any dmsdos utility against the library I just
32: managed to crash the linker :((
33: I have really no idea what stupid things I may have done...
34: Looks like this gcc port is not yet ready for daily use. Sigh. Though it's
35: really an impressive work: all gnu tools under NT...
36:
37: Okay, now Cygnus have released B20 version of their Win32 gcc port, and -
38: guess what - it _worked_, almost out of the box. Even the Configure script
39: runs correctly now. There is a special Makefile, Makefile.cygwinb20,
40: that should be used for this compiler. One thing, though, is bad: the
41: compiler does neither support Unix flock nor Win32 sopen. This means the
42: generated code does not do file locking. Be sure that there is never
43: more than one process that is using a CVF through libdmsdos.
44:
45: The next chance I gave to Microsoft Visual C++ 5.0. Again almost nothing
46: worked (and yes, the IDE also crashed awaking Dr. Watson when I just clicked
47: around in the help in order to learn how to use the IDE...). No need to say
48: that I had to configure dmsdos under Linux. The complete Makefile was even
49: rejected by nmake. So what. I finally wrote a script win32_msc50.bat
50: that compiles the necessary things in a Win32 _console_. Currently, the
51: only useful application is mcdmsdos: it can extract files from a CVF in
52: a Win32 environment. (Just tested: the executable runs even under wine in
53: an xterm :-) )
54:
55: I did not try other compiler versions. It may work with the DJGPP Dos port
56: of gcc and the EMX OS/2 port of gcc. But you may find that the long filenames
57: the dmsdos sources use cause a lot of problems there...
58: Now there's a script called "prepare_dos_8.3" in the src directory that
59: translates all relevant dmsdos files to use 8.3 names. There's no further
60: documentation about this. You are expected to take a look at the script.
61: You are also expected to write your own Makefile for compilation in such an
62: environment. There are lots of problems that may occur in a DOS environment.
63: Sorry, but I can't test everything.
64:
65: Okay, that's what should work under every compiler:
66:
67: * Configure, compile and install dmsdos under Linux.
68: * Copy the whole directory where it compiled to a vfat partition.
69: * Boot a Win32 system and edit the script win32_msc50.bat (on my system
70: I had to setup include and library paths there). If your compiler is not
71: Microsoft Visual C++ 5.0 this may not work and you may have to write
72: a new script from scratch.
73: * Run the script with errors directed into a file.
74: * Hack the source where it fails. Please be sure to surround your changes
75: with appropriate #ifdef's (unless they are real bugs) so I can integrate
76: them into next dmsdos release. Let me know what you had to change and why.
77:
78:
79: B. Driver Level
80: ---------------
81:
82: That's indeed possible. At least, there has been some discussion about using
83: libdmsdos for writing a Win95/98 VXD or a Win NT 4.0 FS driver.
84:
85: Well, I refuse to do that. I'm not a Win32 driver hacker and my knowledge
86: about the Win95/98 or Win NT driver interface is almost zero. But some
87: notes may be interesting, though.
88:
89: Note that libdmsdos is *not* reentrant. If the Win32 system does not ensure
90: exclusive execution of the driver code you must write your own *exclusive*
91: locking interface around all libdmsdos calls, even in read-only mode.
92:
93: Beyond that, you will have to write a full-featured FAT filesystem
94: driver that calls the libdmsdos cluster read and write routines, and link it
95: against libdmsdos. That's almost all. That's not difficult.
96: As FAT is a simple filesystem layout, and the CVFs are FAT12 or FAT16 but
97: never FAT32, each experienced Dos programmer should be able to write that
98: from scratch, at least for 8.3 filenames which would be enough for
99: functionality :) The first trial is always read-only, and that should not be
100: too much work.
101:
102: Note that libdmsdos references some standard C library functions that are
103: not available at driver level. You must write an emulation for all these
104: functions and link it to the driver instead of the standard C library. The
105: emulation needn't be full-featured like the C library. Look at the source
106: if you are in doubt. Well, the read/write/lseek emulation is actually all
107: the low-level disk access :)
108:
109: See doc/libdmsdos.doc for further information about the dmsdos library
110: (including a list of referrenced C library functions and a detailed
111: description of the dmsdos functions the library exports).
112:
113: Let me know if you are a Win32 hacker and want to start such a project :)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.