Kevin A. Foss wrote:
On Sat, 23 Jan 1999 22:15:55 +0100, Frank Heckenbach wrote:
- __OS_DOS__ is defined in Pascal on Dos like systems (including
EMX). It is defined automatically and should not (need to) be defined by the user. It's used in Pascal parts of the RTS (rts/filename.pas [1], e.g. for directory and path separators), in some standard units (DosUnix and Printer) and is available to user programs (I need it for a few things in my own programs).
Okay this is more what I was concerned about (GPC's behavior with __OS_DOS__ defined) and once I get the system working I'll investigate its effects, my only real issue is that OS/2 can use either / or \ as a directory separator internally and I don't know if that will mess up some routines. In fact you can even mix separators within a path. A quick look at the source doesn't show any problems as most of the routines in filename.pas are looking at DirSeparators rather than DirSeparator and the ones using DirSeparator are mostly 'fixing' paths for the OS -- if I read them correctly.
Yes, exactly. The `DirSeparator' char constant is used when appending a slash or converting paths before passing them to libc routines (though this might not even be necessary, I think it shouldn't hurt), and the `DirSeparators' set of char constant is used when checking for directroy separators. Since the situation is the same on DJGPP, I tested it at least moderately.
BTW, other units might need some porting as well:
CRT needs a curses version, but I suppose either or both ncurses and/or PDCurses should work under OS/2 (probably PDCurses would be preferable for EMX, since it runs under Dos as well), so CRT should work after setting some ifdefs. A few system specific functions (which are not vital, however), can be ported as well, cf. crtdospc.h for the DJGPP version for them.
The printer unit needs porting if you want it to use some native printing capabilities of OS/2. (I don't know if there are any, and what they look like, however.) Otherwise, it will currently use the Dos printer device ('lpt1') which might work under OS/2, but perhaps not be optimal, I don't know.
The system unit contains specific MemAvail/MaxAvail routines for DJGPP and mingw. If you want to port them to EMX, go ahead, otherwise the unit will just use the portable (but in this case less efficient) replacements.
If the shell supports I/O redirections beyond the simple ones that Dos' command.com knows, and their syntax is different from bash's, (like DJGPP's redir utility), the DosUnix unit should be adapted.
If accessing I/O ports requires getting special permissions (like under Linux), the ports unit needs adaption.
A few other units require C libraries that ought to just be recompiled for EMX. Binaries can then be stored on Agnes together with the other library binaries.
Frank
PS: Does EMX work again? Last thing I heard was that it didn't work with GCC 2.8.x. Did you fix it, or did EM finally do something about it?
On Sun, 24 Jan 1999 14:55:29 +0100, Frank Heckenbach wrote:
PS: Does EMX work again? Last thing I heard was that it didn't work with GCC 2.8.x. Did you fix it, or did EM finally do something about it?
Well to start at the bottom, yes there is a new EMX (0.9d) and a new gcc (2.8.1) with it -- there has been since like a week after I told Peter there was no 2.8.x yet for OS/2 :) I waited for a new gpc before I started work on updating it for OS/2. I thought 2.8.1 would mean an easy compile of gpc, but there seemed to be more problems than I expected.
I had to back patch EM's work on gcc.c (about 50 lines) into gpc.c , and some differences between c-typeck.c and gpc-typeck.c held me up. [The latter problem is because EM integrates the Jones' bounds checking routines for gcc.] The RTS compiled fine -- needs to be tested more, but pretty good so far. The short of it is that I have a working 19990118 now and once I clean stuff up I should be able to upload the patches and binaries in the next couple days.
Another sticky problem was with the OS_DOS code in gpc.c (ironically considering how this thread started). Basically I dump core when it reaches 'free (cpp_predefines);' [line 1620 or so] which I don't find too unreasonable because I didn't think you could free(3) static globals. Of course the code does work on other systems so maybe it is just EMX being picky. I just #ifdef'd the line out for EMX and it compiles now. There is also a weird looking "If False" block in the same area which looks like the code is still under construction.
As far as the units, I'll look at them later but I have BSDCurses & PDCurses and NCurses is available so CRT should be okay, LPT1 is okay, and I'll have to check the memory stuff. I can do most bash style redirection in the default shell so that should be okay too.
-Kevin -- Kevin A. Foss --- kfoss@mint.net
Kevin A. Foss wrote:
Another sticky problem was with the OS_DOS code in gpc.c (ironically considering how this thread started). Basically I dump core when it reaches 'free (cpp_predefines);' [line 1620 or so] which I don't find too unreasonable because I didn't think you could free(3) static globals. Of course the code does work on other systems so maybe it is just EMX being picky. I just #ifdef'd the line out for EMX and it compiles now.
You can just delete it. It's a plain bug.
There is also a weird looking "If False" block in the same area which looks like the code is still under construction.
Indeed, but I think we can remove the `#if 0' section now since the other one seems to work fine.
Peter
-
Frank Heckenbach -
Kevin A. Foss -
Peter Gerwinski