[M3devel] serial/Cygwin

Mika Nystrom mika at async.caltech.edu
Thu Dec 18 22:21:07 CET 2008


Yes, I don't think the world is a terrible place because people like
you exist :-)

I just think that Cygwin users generally have modest requirements.
They're just trying to get something---anything!---to work on
Windows, and if they want to do anything that's really Windows-specific
I think they/we understand they/we may have to make the effort to
learn a bit about Windows and use the native environment.

What it adds up to, in my opinion, is that one shouldn't screw
things up in the native Windows port (or in the Unix ports) just
to satisfy Cygwin users, who really don't care if Windows feature
XYZ is available.

How many people actually use Modula-3 on Cygwin?  I do... and I
just use it so I can run programs I developed on Unix on random
Windows machines when the owners of those machines have made the
bizarre (to me) decision to run Windows...

If anything, I'd like it if the Cygwin Modula-3 were *less* Windows-y
than it is now.  For instance, the version I use has Windows
file-locking semantics, i.e., default readers-and-writers locking
on all open files, which can be quite annoying when porting from
Unix.  It also uses a different epoch for Time.T.  Not sure if
the current version has these features...
   
     Mika

"Randy Coleburn" writes:
>--=__Part6F4761B2.0__=
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>I do use Cygwin on occasion, but I'm not sure how most Cygwin users feel =
>about it and Modula-3.
>=20
>Mika has a point that if you want to create an environment on Windows that =
>is devoid of Microsoft tools, the Cygwin Modula-3 may be what you are =
>looking for.
>=20
>On the other hand, I am in a camp of folks who don't mind using the =
>Microsoft tools and want Modula-3 to work out of the box on Windows =
>without having to add any other non-Microsoft stuff (like Cygwin).
>=20
>I think it is great for CM3 to be able to support both these camps!
>=20
>Thus, you will find me always advocating for keeping the "CM3 on Windows =
>variant" where it will work on Windows using just the Microsoft tools.  I =
>am happy with the use of Windows threads and the native backend and use of =
>the MS Visual Studio linker.
>=20
>Regards,
>Randy Coleburn
>
>>>> Mika Nystrom <mika at async.caltech.edu> 12/17/2008 10:10 PM >>>
>Do Cygwin users really care about all that stuff?
>
>The point of using Modula-3 on Cygwin is to turn a yucky Windows
>machine as close as possible into a friendly Unix environment...
>not to use a bunch of Microsoft tools and libraries---I would have
>thought that if you wanted to use Visual X-Y-Z then you wouldn't
>be using Cygwin but would be using the native Windows environment?
>
>So yes I find it a bit odd that the ancient PM3-Klagenfurt I still
>occasionally use on Windows uses Windows threads and has its own
>compiler back-end.  But it's kind of cool too and since it's not
>really distinguishable from user-level threads and gcc I just think
>"great" and get on with it.  In fact I'm not even sure it uses
>the integrated back end now that I think about it.
>
>I think what I'm saying is that almost no Cygwin users are terribly
>interested in Microsoft interfaces, and I would bet most Cygwin
>users aren't even aware of the existence of most Microsoft tools.
>They (we) want as little to do with Windows as possible....
>
>     Mika
>
>Jay writes:
>>--_c7ada8a5-5684-4472-b0c7-b49c8c279dc2_
>>Content-Type: text/plain; charset=3D"iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>
>>
>>From: TonyTo: jay
>>I would have thought of CygWin as a POSIX platform that just happens to =
>hav=3D
>>e Windows underneath.  Did we go round this roundabout before?
>>
>>
>>
>>
>>
>>It's more complicated than that.
>>It isn't just one bit.
>>There's a few factors=3D2C that people care more and less about.
>>  GUI library  -- Win32 or X
>>  thread library  -- pthreads or Win32 (or user threads)=3D20
>>  file system path representation -- forward slashes or backward slashes  =
> =3D
>> This seems to be what people care most about -- to see forward slashes.
>>  C compiler -- Visual C++ cl or Cygwin/GNU gcc
>>  linker -- Visual C++ link or Cygwin/GNU ld=3D20
>>  C runtime -- msvcr*.dll or cygwin1.dll=3D20
>>  integrated backend or not     The integrated backend is way faster=3D2C =
>but=3D
>> doesn't yet support 64bit LONGINT.
>>  which debugger/symbol format -- gdb/stabs or windbg/VisuaStudio/CodeView=
>/=3D
>>pdb
>>Many of these factors are independent of each other=3D2C but not =
>entirely.
>>Compiler/linker directly lead to which debugger you can use=3D2C since  =
>they =3D
>>each use different formats.
>>Well=3D2C you can use either debugger=3D2C but..without symbols..at least =
>for s=3D
>>ome modules.
>>The Cygwin C runtime and Visual C++ linker disagreeon the name of =
>__ImageBa=3D
>>se=3D2C so you can't link to the Cygwin C runtime with theVisual C++ =
>linker. =3D
>>This is probably fixable at least in one combination withan alias =
>(ability =3D
>>to link Cygwin C runtime with Visual C++ linker=3D3B I don'tknow if =
>Cygwin/GN=3D
>>U ld understands aliases).
>>I have also found that Cygwin produces incorrectimport .libs=3D2C perhaps =
>the=3D
>>ir linker somehow accepts them.
>>=3D20
>>Cygwin can program the Win32 GUI=3D2C but there is an issue with passing =
>8 by=3D
>>te structs by value to __stdcall functions=3D2C the function name isn't =
>mangl=3D
>>ed correctly and linking fails.
>>It is a bit of a combinatorial explosion.As the system stands=3D2C you =
>can co=3D
>>ntrol each bit in the config file=3D2C andmultiple combinations might =
>work=3D2C=3D
>> though I don't run any combinatorial tests.
>>Three combinations are "identified" (named=3D2C spoken of) and have had =
>some =3D
>>development testing.NT386=3D2C NT386MINGNU (which I think should be =
>called I3=3D
>>86_MINGWIN)=3D2C and NT386GNU (which I think should be called I386_CYGWIN)=



More information about the M3devel mailing list