<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> If anything, I'd like it if the Cygwin Modula-3 were *less* Windows-y<BR><BR>
<BR>
Well, here I can cop-out and say: "Hey, it just uses Cygwin".<BR>
Other than a possible avenue for the serial code.<BR>
And other than threads.<BR>
<BR>
> Unix. It also uses a different epoch for Time.T. Not sure if<BR><BR>
I'm pretty sure that's not the case now.<BR>
It very likely uses 31bit seconds since 1970, and will break around 2038.<BR>
The hypothetical AMD64_CYGWIN would likely use 63bit seconds since 1970, so better.<BR>
msvcr*.dll offers 63bits seconds since 1970, you configure it with a #define.<BR>
(I say 31 or 63, because they are signed numbers probably, but negative numbers aren't<BR>
considered valid. They really should be unsigned, and with a much earlier epoch...I<BR>
realize files don't exist before these times, but it's nice to have one time format apply<BR>
to more than just files, and there's certainly a legitimate need to represent earlier times..)<BR>
<BR>
<BR>
Oh..well, yeah, I did name files foo.lib and not libfoo.a.<BR>
File naming was another question that came up, along the lines of "What is Cygwin?".<BR>
People said they didn't care.<BR>
<BR>
<BR>
Similarly, executables named "foo" or "foo.exe"?<BR>
.dlls named "foo.so" or "foo.dll".<BR>
Cygwin actually uses foo.dll (or libfoo.dll, er..cygfoo.dll actually) and foo.exe.<BR>
foo.so works fine, and "foo" works fine, at least on NT.<BR>
bash will run it. cmd will run it if you add "." to %PATHEXT%.<BR>
Apparently Win9x doesn't like it, and Cygwin historically supported Win9x (still today, but not for much longer, not with the next major release). So here you can see, that some typical Posix characteristics are not followed by Cygwin.<BR>
<BR>
Interix actually does use extensionless executables. You can see the evidence in taskmgr for example.<BR>
<BR>
I had it using foo.so (libfoo.so?) and "foo" for a bit, but since people didn't care, and Cygwin didn't do that, I put it back. It was pretty easy to go back and forth, like by fiddling with the "naming conventions" setting.<BR>
(Which, it turns out, I think, was never really implemented correctly -- there are host and target conventions and I think they were confused.)<BR>
<BR>
Wait a sec, this does remind me. The cygfoo.dll convention has the benefit of being able to mix stuff in the same directory or along the same %PATH%. I thought that not useful, since .exes would still clash in name, but maybe?<BR>
<BR>
<BR>
I will put serial back for non-Cygwin, really.<BR>
And I'll fix SOLsun/gnu.<BR>
Soon.<BR>
<BR>
<BR>
- Jay<BR><BR><BR>> To: rcoleburn@scires.com<BR>> To: m3devel@elegosoft.com<BR>> Date: Thu, 18 Dec 2008 13:21:07 -0800<BR>> From: mika@async.caltech.edu<BR>> Subject: Re: [M3devel] serial/Cygwin<BR>> <BR>> Yes, I don't think the world is a terrible place because people like<BR>> you exist :-)<BR>> <BR>> I just think that Cygwin users generally have modest requirements.<BR>> They're just trying to get something---anything!---to work on<BR>> Windows, and if they want to do anything that's really Windows-specific<BR>> I think they/we understand they/we may have to make the effort to<BR>> learn a bit about Windows and use the native environment.<BR>> <BR>> What it adds up to, in my opinion, is that one shouldn't screw<BR>> things up in the native Windows port (or in the Unix ports) just<BR>> to satisfy Cygwin users, who really don't care if Windows feature<BR>> XYZ is available.<BR>> <BR>> How many people actually use Modula-3 on Cygwin? I do... and I<BR>> just use it so I can run programs I developed on Unix on random<BR>> Windows machines when the owners of those machines have made the<BR>> bizarre (to me) decision to run Windows...<BR>> <BR>> If anything, I'd like it if the Cygwin Modula-3 were *less* Windows-y<BR>> than it is now. For instance, the version I use has Windows<BR>> file-locking semantics, i.e., default readers-and-writers locking<BR>> on all open files, which can be quite annoying when porting from<BR>> Unix. It also uses a different epoch for Time.T. Not sure if<BR>> the current version has these features...<BR>> <BR>> Mika<BR>> <BR>> "Randy Coleburn" writes:<BR>> >--=__Part6F4761B2.0__=<BR>> >Content-Type: text/plain; charset=US-ASCII<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> >I do use Cygwin on occasion, but I'm not sure how most Cygwin users feel =<BR>> >about it and Modula-3.<BR>> >=20<BR>> >Mika has a point that if you want to create an environment on Windows that =<BR>> >is devoid of Microsoft tools, the Cygwin Modula-3 may be what you are =<BR>> >looking for.<BR>> >=20<BR>> >On the other hand, I am in a camp of folks who don't mind using the =<BR>> >Microsoft tools and want Modula-3 to work out of the box on Windows =<BR>> >without having to add any other non-Microsoft stuff (like Cygwin).<BR>> >=20<BR>> >I think it is great for CM3 to be able to support both these camps!<BR>> >=20<BR>> >Thus, you will find me always advocating for keeping the "CM3 on Windows =<BR>> >variant" where it will work on Windows using just the Microsoft tools. I =<BR>> >am happy with the use of Windows threads and the native backend and use of =<BR>> >the MS Visual Studio linker.<BR>> >=20<BR>> >Regards,<BR>> >Randy Coleburn<BR>> ><BR>> >>>> Mika Nystrom <mika@async.caltech.edu> 12/17/2008 10:10 PM >>><BR>> >Do Cygwin users really care about all that stuff?<BR>> ><BR>> >The point of using Modula-3 on Cygwin is to turn a yucky Windows<BR>> >machine as close as possible into a friendly Unix environment...<BR>> >not to use a bunch of Microsoft tools and libraries---I would have<BR>> >thought that if you wanted to use Visual X-Y-Z then you wouldn't<BR>> >be using Cygwin but would be using the native Windows environment?<BR>> ><BR>> >So yes I find it a bit odd that the ancient PM3-Klagenfurt I still<BR>> >occasionally use on Windows uses Windows threads and has its own<BR>> >compiler back-end. But it's kind of cool too and since it's not<BR>> >really distinguishable from user-level threads and gcc I just think<BR>> >"great" and get on with it. In fact I'm not even sure it uses<BR>> >the integrated back end now that I think about it.<BR>> ><BR>> >I think what I'm saying is that almost no Cygwin users are terribly<BR>> >interested in Microsoft interfaces, and I would bet most Cygwin<BR>> >users aren't even aware of the existence of most Microsoft tools.<BR>> >They (we) want as little to do with Windows as possible....<BR>> ><BR>> > Mika<BR>> ><BR>> >Jay writes:<BR>> >>--_c7ada8a5-5684-4472-b0c7-b49c8c279dc2_<BR>> >>Content-Type: text/plain; charset=3D"iso-8859-1"<BR>> >>Content-Transfer-Encoding: quoted-printable<BR>> >><BR>> >><BR>> >><BR>> >>From: TonyTo: jay<BR>> >>I would have thought of CygWin as a POSIX platform that just happens to =<BR>> >hav=3D<BR>> >>e Windows underneath. Did we go round this roundabout before?<BR>> >><BR>> >><BR>> >><BR>> >><BR>> >><BR>> >>It's more complicated than that.<BR>> >>It isn't just one bit.<BR>> >>There's a few factors=3D2C that people care more and less about.<BR>> >> GUI library -- Win32 or X<BR>> >> thread library -- pthreads or Win32 (or user threads)=3D20<BR>> >> file system path representation -- forward slashes or backward slashes =<BR>> > =3D<BR>> >> This seems to be what people care most about -- to see forward slashes.<BR>> >> C compiler -- Visual C++ cl or Cygwin/GNU gcc<BR>> >> linker -- Visual C++ link or Cygwin/GNU ld=3D20<BR>> >> C runtime -- msvcr*.dll or cygwin1.dll=3D20<BR>> >> integrated backend or not The integrated backend is way faster=3D2C =<BR>> >but=3D<BR>> >> doesn't yet support 64bit LONGINT.<BR>> >> which debugger/symbol format -- gdb/stabs or windbg/VisuaStudio/CodeView=<BR>> >/=3D<BR>> >>pdb<BR>> >>Many of these factors are independent of each other=3D2C but not =<BR>> >entirely.<BR>> >>Compiler/linker directly lead to which debugger you can use=3D2C since =<BR>> >they =3D<BR>> >>each use different formats.<BR>> >>Well=3D2C you can use either debugger=3D2C but..without symbols..at least =<BR>> >for s=3D<BR>> >>ome modules.<BR>> >>The Cygwin C runtime and Visual C++ linker disagreeon the name of =<BR>> >__ImageBa=3D<BR>> >>se=3D2C so you can't link to the Cygwin C runtime with theVisual C++ =<BR>> >linker. =3D<BR>> >>This is probably fixable at least in one combination withan alias =<BR>> >(ability =3D<BR>> >>to link Cygwin C runtime with Visual C++ linker=3D3B I don'tknow if =<BR>> >Cygwin/GN=3D<BR>> >>U ld understands aliases).<BR>> >>I have also found that Cygwin produces incorrectimport .libs=3D2C perhaps =<BR>> >the=3D<BR>> >>ir linker somehow accepts them.<BR>> >>=3D20<BR>> >>Cygwin can program the Win32 GUI=3D2C but there is an issue with passing =<BR>> >8 by=3D<BR>> >>te structs by value to __stdcall functions=3D2C the function name isn't =<BR>> >mangl=3D<BR>> >>ed correctly and linking fails.<BR>> >>It is a bit of a combinatorial explosion.As the system stands=3D2C you =<BR>> >can co=3D<BR>> >>ntrol each bit in the config file=3D2C andmultiple combinations might =<BR>> >work=3D2C=3D<BR>> >> though I don't run any combinatorial tests.<BR>> >>Three combinations are "identified" (named=3D2C spoken of) and have had =<BR>> >some =3D<BR>> >>development testing.NT386=3D2C NT386MINGNU (which I think should be =<BR>> >called I3=3D<BR>> >>86_MINGWIN)=3D2C and NT386GNU (which I think should be called I386_CYGWIN)=<BR><BR></body>
</html>