<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Mika, while I agree such a target might be interesting, and might just about work now, there is another target that is also definitely interesting, and more interesting to some folks, and perhaps more efficient, smaller, faster. There needs to be a way to ask for one or the other.<BR>
People want one. People want the other. I think I've seen about two people ask for each. Wow a small number.<BR>
<BR>
There are tools and there is runtime, and you can pick and chose.<BR>
But too many choices and people get confused, so there's a need to prepackage some combinations under small names.<BR>
<BR>
At the moment, NT386GNU means use GNU tools, but otherwise be like NT386.<BR>
<BR>
There are really several variables in all this.<BR>
There are three threading models available, and they probably all work or could be easily made to.<BR>
There are two underlying GUI libraries, ditto.<BR>
There is PERHAPS Win9x compatibility to consider. Cygwin is dropping that in newer versions.<BR>
<BR>
What is a "target"? vs. what is a "configuration"?<BR>
Odds are fairly good that if you merely alter $PATH one way or the other, and undo my small changes below to what m3makefile includes what, and what cm3 assumes OSTYPE is, Cygwin will work, at least as well as I have NT386GNU otherwise working. That is, all three of these targets are so darn similar that is almost just a matter of "configuration" and could perhaps be made so. I am reluctant to blow up the size of jmpbuf to enable arbitrary mixing however.<BR>
<BR>
The tricky part is not so much making it work, but what to call it, how to expose it to users, as well as perhaps streamlining the setup.<BR>
I am better at "making it work" however and am open to suggestions all around.<BR>
<BR>
There is yet another direction and it is obviously the direction things were going -- neither GNU nor MS tools.<BR>
There is already the x86 backend written in Modula-3. It is noticably very much faster than the gcc backend. There is very little C code in the system and it could probably all be rewritten in Modula-3..the beauty of its "optional safety"...though your point is very valid as to outside the system. There is already a start of a runtime linker that loads .objs. The C runtime dependency is very very minimal already. Finish those last two points and you have a "self contained" system , from a certain point of view, a common point of view, though there is still the dependency on kernel32.dll, user32.dll, gdi32.dll, the "OS" as people like to label it, though it is really just another bunch of code in most respects and not something as "special" as people think, and you can be more or less dependent on it as well -- remember that Modula-3 when using the vtalarm threads does its own scheduling (I think), a task people normally think of as provided by an "OS".<BR>
(I believe Mary Fernandez already wrote a relatively easily retargetable linker and debugger in Modula-3, but I could be wrong.)<BR>
<BR>
I just realized another target -- NT386-Interix or such, these days known as "Services for Unix" and I think a free download.<BR>
This is YET ANOTHER very Posixish environment.<BR>
<BR>
As well, there is the question from earlier of "What is Posix?"<BR>
It's not like Microsoft doesn't provide open/read/write/close. They do.<BR>
What all is in the Cygwin headers that people want?<BR>
The availability of sh should have little impact on your Modula-3 code, right? You aren't running command lines in it, right?<BR>
It's not like portable standard C and C++ can't be compiled just as well, if not better and faster, by the Microsoft compiler. It can be.<BR>
I realize there are details, levels of ANSI conformity, and there are language extensions on both sides.<BR>
<BR>
Now, since I have been debugging stuff lately, I realize there could be a big question as to debuggers.<BR>
More importantly, debug information format.<BR>
My experience lately is that this is an either/or choice, and you can't have it both ways.<BR>
If you are very used to gdb/m3gdb, you must use the GNU tools. But you don't need Cygwin (except to build m3gdb or acquire gdb).<BR>
If you are very used to windbg/ntsd/cdb/Visual Studio, well you must use the non-gcc backend, the Microsoft C compiler for the little bit of C/C++ if you want to debug it, the Microsoft linker I assume, however you aren't going to be likely happy. The non-gcc backend only outputs line number information, no types, no locals. It's not a pleasant experience, but at least you can see the stack. You can also to some extent use both. You can build your code for either platform and flit around between the two. Or you can flit around between debuggers and deal with a lack of symbols in one, and just poke around in memory, using information gleaned from the other.<BR>
But again, this doesn't have much to do with Cygwin or not Cygwin. I've only been going at this a short time, so maybe gdb does better with the Cygwin output. I don't know.<BR>
<BR>
Sorry for the tone. We are actually in agreement, essentially. I have been largely on the fence and just asking what to call things, and everyone else is clearly on one side or the other. I personally will not use Cygwin if I can help it, but I do use it for cvs and ssh at least. I actually hardlink swaths of it into my Windows directory, the useful command line utilities, that which likely one non-configurable version would suffice -- ie: not gcc/ld/ar/as. If there was one true gcc/ld/ar/as, I would hardlink it in too. Likewise with cl/link. e.g. I have windiff in there, but not cl/link. I don't want that cygwin1.dll dependency and then have to understand the licensing...<BR>
<BR>
So the non-Cygwin target came first. It is easier. It is faster. It is what I prefer.<BR>
Maybe there will be a Cygwin target. Maybe someone else will provide it?<BR>
<BR>
It should be clear btw that the real work here was all done for us in gcc/ld, and cm3. The rest is easier.<BR>
<BR>
Besides..who is going to do the work here, and who is going to use it?<BR>
Are Windows users asking for a more Posixish system or are Posix users saying what Windows should be like? Will they move to it?<BR>
Bah humbug.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> To: hosking@cs.purdue.edu<BR>> To: m3devel@elegosoft.com<BR>> Date: Sat, 19 Jan 2008 19:46:03 -0800<BR>> From: mika@async.caltech.edu<BR>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR>> <BR>> Can I add a perhaps obvious observation?<BR>> <BR>> NT386GNU must, of all things, mean that the code will compile and<BR>> link cleanly, with a minimum of fuss, against Cygwin's headers<BR>> and libraries. I have never used MS's C tools so I don't know<BR>> if this is the case with them. It is of course the case when<BR>> you use GNU ld, etc.<BR>> <BR>> When building large software in Modula-3 it's almost inevitable<BR>> that, since the language is used by so few people, you will have a<BR>> need to call out to C code (or Fortran code, or some other compiled<BR>> code, with C interfaces). If you develop on Unix and use Cygwin<BR>> to port to Windows, it makes no sense to distinguish between NT386<BR>> and NT386GNU unless the latter has pretty much the same environment<BR>> as the Unix system.<BR>> <BR>> Mika<BR>> <BR>> Tony Hosking writes:<BR>> >So, I am very confused now. Does NT386GNU no longer mean use of the <BR>> >full set of GNU tools m3cc/ld/as, as would be available under <BR>> >Cygwin? I thought the point of this was to be able to run in as much <BR>> >of a GNU environment as possible. GNU to me means the whole <BR>> >toolsuite not just m3cc. To me, a GNU-based environment on Windows <BR>> >holds great attraction, since it consists of tools that I generally <BR>> >always install on Windows, that I know, and are similar to the other <BR>> >platforms I use.<BR>> ><BR>> >On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:<BR>> ><BR>> >> CVSROOT: /usr/cvs<BR>> >> Changes by: jkrell@birch. 08/01/19 04:11:34<BR>> >><BR>> >> Modified files:<BR>> >> cm3/m3-libs/m3core/src/runtime/: m3makefile<BR>> >> cm3/m3-sys/cminstall/src/config/: NT386GNU<BR>> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3<BR>> >> cm3/m3-sys/m3middle/src/: Target.m3<BR>> >><BR>> >> Log message:<BR>> >> m3-sys/m3middle/src/Target.m3<BR>> >> m3-libs/m3core/src/runtime/m3makefile<BR>> >> m3-sys\m3front\src\builtinInfo\InfoModule.m3<BR>> >> <BR>> >> switch NT386GNU to be Win32 instead of POSIX<BR>> >> switch NT386GNU to _setjmp instead of setjmp<BR>> >> jmp_buf size still big like Cygwin<BR>> >> rewrite NT386GNU config file -- almost identical to NT386<BR>> >> mingwin required for building Modula-3 programs<BR>> >> mingwin AND msys required for building m3cc<BR>> >> <BR>> >> To boot:<BR>> >> <BR>> >> install Python (www.activestate.com)<BR>> >> <BR>> >> have a working NT386 system<BR>> >> get current source<BR>> >> Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was <BR>> >> taken by Unix)<BR>> >> <BR>> >> get and install binary distribution (5.1.3 works, anything newer <BR>> >> should work)<BR>> >> I install to c:\cm3<BR>> >> copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin <BR>> >> \cm3.cfg<BR>> >> <BR>> >> Have a Visual C++ toolset (cl and link)<BR>> >> and run the vcvars link on the start menu (this can/will be made <BR>> >> easier)<BR>> >> Almost any version should work.<BR>> >> if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe<BR>> >> and get a newer from such as from the Platform SDK. Otherwise it <BR>> >> crashes.<BR>> >> This is not specific to NT386GNU, just that I recently removed the <BR>> >> Platform SDK<BR>> >> from my %PATH%.<BR>> >> <BR>> >> cd %CVSROOT%\scripts\python<BR>> >> .\upgrade<BR>> >> <BR>> >> install msys and mingwin from http://www.mingw.org (links to <BR>> >> SourceForge)<BR>> >> for mingwin, you only need the "base"<BR>> >> msys tells you to avoid mingwin make, in favor of msys make, and I <BR>> >> did that<BR>> >> <BR>> >> I install to the defaults<BR>> >> c:\msys\1.0<BR>> >> c:\mingw<BR>> >> <BR>> >> if you don't install to the defaults, add<BR>> >> <msys>\bin and <mingwin\bin to $PATH (in which order? I add<BR>> >> to the start, but which order between the two?)<BR>> >> <BR>> >> if you do install to the defaults, scripts\python will fix path <BR>> >> for you,<BR>> >> if there is no gcc/as/sh on our $PATH<BR>> >> <BR>> >> cd %CVSROOT%\scripts\python<BR>> >> upgrade && bootntgnu<BR>> >> <BR>> >> NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still <BR>> >> progress.<BR>> >> <BR>> >> These instructions inevitably to be further tested and refined and <BR>> >> placed elsewhere!<BR><BR><br /><hr />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>
</html>