[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OOC Garbage Collector Proposal



Hallo!

If I had to decide between a WIN32 version of OOC or a new gc, I would
vote for WIN32, just because to could give use a chance to port

> Most of the stuff isn't exactly Unix-specific.  The libraries use some
> ANSI and POSIX functions, plus a BSD extension or two.   Most of them
> should be available under Win32, too.

With the help of the OOC I was able to compile OO2C under Windows NT
using the CygnusWin32 port of gcc (and one single patch). I was also
able to compile a little "HelloWorld". But there some obvious problems.
The configure script didn't work, because executeable having *.exe
suffixes. The compiler had to be started more than once, since it
left out (for no reason) *.c files to compile.

> The only other system-dependent part is file name handling.  File name
> manipulation is currently done by module Filenames.Mod, it probably
> needs to be adjusted to the different naming conventions.  This module
> is marked as "obsolete", but until someone comes up with a more
> flexible mechanism to deal with file names it's all we got.

The ggc port as far as I know handles the differences itself. Thus OO2C
compiled rather smoothly. Other C compilers may not do this. One major
problem is the differences of textfiles and binary files under Windows
and DOS. The patch mentioned above explicitely set binary mode for all
files (textmode is the default). Otherwise the internal file caching of
Oberon will get confused. Oone must find a solution to at least support
such stuff better in the OOC io modules.

Of course, for VisualOberon one needs access to the WIN32 API, this
includes support for the various function calling mechanism under
Windows ("__cdecl"-stuff) and an adaption of (a subset of) the Windows
headers. After that a port of VisualOberon should be straight forward.

-- 
Gru...
       Tim.