<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Good point Olaf, thanks for refocusing us. (and here I go again...)<BR>
<BR>
The behavior of NT386 is not in question.<BR>
I churned the underlying code (<EM>just the default config file</EM>, which "hopefully" nobody has to change at all) and it can/does now share with others, but "nobody should notice anything" that is using NT386 (famous last words..nothing under my sleeve...)<BR>
<BR>
NT386GNU's behavior is the question. I made it more like NT386 that some/all folks desire while still using the gcc backend, which is goodness, from a certain point of view, but not everything.<BR>
Perhaps nobody wants the in between behavior, granted.<BR>
<BR>
However if there are people really eager for LONGINT on NT386, then "NT386MINGNU" will be it for now.<BR>
That's it's critical innovation, perhaps.<BR>
I was taking too long on the integrated backend changes. I still have stuff sitting around there.<BR>
And a slower build, with less efficient code without the -O flag but oh well.<BR>
<BR>
>> (or NT386_CYGWIN or whatever) <BR>
<BR>
I assume that name is out of the question. But if we are still talking about this (!) and still open to such changes, then I like NT386_CYGWIN, NT386_MINGWIN, NT386_MINGNU, <FONT face="">I386_CYGWIN, <FONT face="">I386_MINGWIN</FONT>, <FONT face="">I386_</FONT>NT_CYG, <FONT face="">I386_NT_?, and simlar with "x86" replacing I386, or maybe I686, maybe drop the "i". I used to use a system that didn't like leading numbers on file names, only latter, but I think that's now always allowed.</FONT></FONT><BR>
<BR>
If we must derive from (and keep) the existing NT386 and NT386GNU names, then NT386MINGNU I like.<BR>
<BR>
In any case, my plan remains, for the actual "target" to be NT386. These other names are only file names and have less impact on the system. As well, you know that function over in m3cc\m3makefile and m3gdb\m3makefile? How does that compare with the GNU_PLATFORM defined in the individual config files? Seems redundant, eh? So that reduces slightly this impact. As I said..cm3.exe itself has only a few differences between NT386 and other similar, and adequate bits via "backend mode" and perhaps "os type". cm3 cares about jmpbuf size but it doesn't care about threading library, window library, c library. Maybe hopefully some day it will care about exception handling model but for now, the same across all targets.<BR>
Really we're talking about 10, maybe 30 lines of diff to push this stuff much further along..depending on how much Cygwin "just works".<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> From: <A href="mailto:wagner@elegosoft.com">wagner@elegosoft.com</A><BR>
><BR>> > it as well. Summarized I strongly vote for NT386 being Windows with least<BR>> > dependencies on other packages.<BR>> <BR>> There has never been a question about this. But there are other who<BR>> prefer something more POSIXish like Cygwin, which is why other targets<BR>> like NT386GNU (or NT386_CYGWIN or whatever) are needed.<BR>> <BR>> Olaf<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>