[M3devel] serial/Cygwin

[Jay]

From: TonyTo: jay
I would have thought of CygWin as a POSIX platform that just happens to have 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, that people care more and less about.
  GUI library  -- Win32 or X
  thread library  -- pthreads or Win32 (or user threads) 
  file system path representation -- forward slashes or backward slashes    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 
  C runtime -- msvcr*.dll or cygwin1.dll 
  integrated backend or not     The integrated backend is way faster, but doesn't yet support 64bit LONGINT.
  which debugger/symbol format -- gdb/stabs or windbg/VisuaStudio/CodeView/pdb
Many of these factors are independent of each other, but not entirely.
Compiler/linker directly lead to which debugger you can use, since  they each use different formats.
Well, you can use either debugger, but..without symbols..at least for some modules.
The Cygwin C runtime and Visual C++ linker disagreeon the name of __ImageBase, so you can't link to the Cygwin C runtime with theVisual C++ linker. This is probably fixable at least in one combination withan alias (ability to link Cygwin C runtime with Visual C++ linker; I don'tknow if Cygwin/GNU ld understands aliases).
I have also found that Cygwin produces incorrectimport .libs, perhaps their linker somehow accepts them.
 
Cygwin can program the Win32 GUI, but there is an issue with passing 8 byte structs by value to __stdcall functions, the function name isn't mangled correctly and linking fails.
It is a bit of a combinatorial explosion.As the system stands, you can control each bit in the config file, andmultiple combinations might work, though I don't run any combinatorial tests.
Three combinations are "identified" (named, spoken of) and have had some development testing.NT386, NT386MINGNU (which I think should be called I386_MINGWIN), and NT386GNU (which I think should be called I386_CYGWIN).
Furthermore, you can imagine I386_INTERIX and I386_UWIN (I forget if that's the name).Interix and UWIN being two other very viable Posix layers on Windows.Interix has been renamed a few times. It is called "SFU" -- services for Unix, and I don't know,like SUA -- services for unix applications, and I think there's another name.It is a free download from Microsoft for x86 Windows < Vista, and is an optional component in Vista.It has its pluses and minuses..not now.
Anyway, in conversation here, one of the main things that people DO NOT care aboutis which thread library is used.
I believe it was asserted that PM3/NT386GNU did work, but that it might have used Win32 threads.
And maybe never had any GUI?
I tried getting pthreads to work, but gave up debugging it.Perhaps a fresh go at debugging it would pan out..but I'm really not too interested..
I also have no interest in user threads. I believe they are never warranted, excepton old systems that don't have kernel threads, like the hypothetical DJGPP port.
I never brought up the issue of serial ports.I ASSUMED that almost nobody uses them, and anyone that does use them, doesn'tcare if they are implemented using Cygwin or Win32, as long as they work.
I ASSUME there is no interop issue, like getting an int fd from the serial portand passing it to select() or close, or getting a Win32 HANDLE and passing itto WaitForSingleObject, but I could be wrong here, certainly.
I didn't look into if Cygwin is complete enough to implement them.I consider serial ports to be kind of out on the fringe..that it wouldn't be surprising if Cygwin didn't implement them..but I didn't look. Heck, I tried building minicom on some non-Linux system(s) recently and it failed miserably. I don't know if there is even much Posix portability option for serial port programming.
Sure..I debug over a serial port, and lately have machines I can't get videoout of (Itanium) or even seem to have no video hardware (Sun), so I use a serial consolefor initial install (recent achievement :) still haven't installed over network..), but that's still imho a big step away from writing code that uses the serial port.(And NetBSD doesn't support the local video on SGI O2, but I'm running OpenBSD there for now.)
 
Anyway, there are a few ways to look at this issue.More and less trivial.
A trivial view is:  Get the filtering to work. Build serial on all platforms but Cygwin.   Or see if the Posix code will work.
  I'd be surprised if the intersection of Cygwin x Modula-3 x serial port programmers is not 0, but could be. I actually don't think anyone is using Cygwin x Modula-3.
Another view is:  Get the Win32 serial code to work on Cygwin.  The code is already there, and buildable, but building in a system that also builds FilePosix.m3   breaks Modula-3 rules, you end up with two implementations of the File interface. What you want, I think, is FilePosix.m3 to provide the File interface, and FileWin32.m3 to provide   just its own specific FileWin32 interface.  I think this is a simple transform of the code.
Anyway, not a big deal...my tone here...is rushed, not rude, sorry.Maybe I'll get the truncation I deserve. :)
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081217/63a3f93e/attachment-0002.html>