Hi:<br>Yes, there is some kind of support for /dev file system, though I have not used it, I think this documentation is reliable:<br>http://www.cygwin.com/cygwin-ug-net/using-specialnames.html<br><br>Well after all the things you are right because the license issues maybe affect the decision of some users of making use of cygwin (NT386GNU): <br>Let's suppose that there is some user(s) interested more in WIN32 platform so we can expose a better support for that on NT386_MINGW  or in current NT386. <br>The NT386GNU user(s) would be more appropriate for those interested in using more tools of a POSIX enviroment, let's say grep, gaw, POSIX functions of time, x server/client enviroment and all the stuff you can get to work on cygwin. So the second user has to pay (if he needs) attention on the licensing issues of all of the used tools.  <br><br>Thanks for the comments.<br>Daniel Benavides<br><br><b><i>Jay <jayk123@hotmail.com></i></b> wrote:<blockquote class="replbq"
 style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">   <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> Daniel, yes it's true cygwin has like -mno-cygwin or something. I will have to try that.<br>Currently msys is required to build m3cc and cygwin is required to build m3gdb.<br>   m3gdb didn't have any type information anyway, so if you install cygwin, you can just use its gdb.<br>   (Note that cygwin is highly modular/package-based, so you can pick and chose what you install, there are many many many choices, so you don't automatically get gdb, you don't automatically even get gcc or ld/binutils.)<br>  <br> Otherwise just MinGWin is required.<br> Cygwin might just work. I'll try it before much longer.<br>  <br> Is someone going to go ahead and create a new target? I guess I'm about able to.<br> I think I finally fixed the major crash so can..take a break
 and then continue. Wow that was tedious.<br> Once I can get a MinGWin distribution, I want to look at the pixmap bug, before looking into this new target..<br> Maybe someone will beat me to it though?<br>  <br> /dev does not appear in Cygwin, at least not with cd and ls on my system.<br> I expect /dev/null will work. I do have a very limited installed of Cygwin now, as I was trying to understand roughly what is needed. I don't know what to expect from /dev in Cygwin. You might be asking for too much.<br>  <br> $ ls /dev/null<br>/dev/null<br> <a href="mailto:Jay@jay-win1">Jay@jay-win1</a> /<br>$ ls /proc<br>1312  cpuinfo  meminfo     registry  stat    version<br>3936  loadavg  partitions  self      uptime<br> <a href="mailto:Jay@jay-win1">Jay@jay-win1</a> /<br>$ ls /dev<br>ls: cannot access /dev: No such file or directory<br> $ ls /dev/tty<br>/dev/tty<br> $ ls /dev/con<br>ls:
 cannot access /dev/con: No such file or directory<br> <a href="mailto:Jay@jay-win1">Jay@jay-win1</a> /<br>$ ls /dev/fd0<br>/dev/fd0<br> <a href="mailto:Jay@jay-win1">Jay@jay-win1</a> /<br>$ ls /dev/fd*<br>ls: cannot access /dev/fd*: No such file or directory<br> <a href="mailto:Jay@jay-win1">Jay@jay-win1</a> /<br>$ ls /dev/hd0<br>ls: cannot access /dev/hd0: No such file or directory<br> <a href="mailto:Jay@jay-win1">Jay@jay-win1</a> /<br>$ ls /dev/sc*<br>ls: cannot access /dev/sc*: No such file or directory<br><br> I'm not sure what all to guess here.<br> fd0 appears but I don't have a floppy disk.<br>  <br> $ cat /proc/uptime<br>41101.28 32423.71<br> <a href="mailto:Jay@jay-win1">Jay@jay-win1</a> /<br>$ cat /proc/version<br>CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2007-12-14 19:21<br>  <br> I'm inclined not to make any cygwin binary distributions until further reading of the license...<br>  <br> There's still the X Windows vs. Win32 question...<br>  <br>
  - Jay<br><br> <blockquote> <hr id="EC_stopSpelling"> Date: Sun, 20 Jan 2008 21:41:23 +0100<br>From: dabenavidesd@yahoo.es<br>Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br>To: jayk123@hotmail.com; wagner@elegosoft.com; m3devel@elegosoft.com<br><br>Hi:<br>I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment.<br>The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a <a title="MinGW" style="color: rgb(0, 0, 0);" href="http://en.wikipedia.org/wiki/MinGW" target="_blank">MinGW</a><span style="color: rgb(0, 0, 0);">/</span><a title="MSYS" style="color: rgb(0, 0, 0);" href="http://en.wikipedia.org/wiki/MSYS" target="_blank">MSYS</a>
 enviroment.<br>Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same.<br>So Jay, m3cc could be built on a cygwin enviroment and m3gdb?<br>If so, we can think in those two separeted platforms? although  cooperative for m3 developers.<br>I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform.<br><br>Thanks<br><br><br><b><i>Jay <jayk123@hotmail.com></i></b> wrote:  <blockquote class="EC_replbq" style="padding-left: 5px; margin-left: 5px;"> <style> .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass EC_body.hmmessage {font-size:10pt;font-family:Tahoma;} </style> > the infrastructure. So I'd rather vote that only new
 targets get<br>> more systematic names.<br><br>Of course, though the existing names suggest new names, and<br>not clear the value of the existing NT386GNU. Ie. is there a benefit<br>to keep it in use with some meaning or not?<br> <br>Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin.<br>I think it holds sigaction state besides register state.<br> <br>"NT" and "Win" seem redundant.<br> I386_MINGWIN? <br> I386_CYGWIN? <br> NT386_GNU? <br> NT386_MINGNU? <br> <br>Ok, I admit that<br>  NT386_CYGWIN<br>  NT386_MINGWIN<br> <br>despite the redundancy, clearly point to existing projects that probably have name recognition.<br>And building from NT386 is reasonable -- as was I saying about existing names influencing new names.<br> <br>A C generating backend gets you perhaps easier retargeting as well.<br>I do see there is "MINGWIN64" out there, for AMD64.<br>Not sure what the state of IA64 is though...<br>(See -- you
 should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.)<br> <br>I also would agree that creating one target instead of two is probably a good idea -- seems easier.<br> <br>I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use?<br>If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.)<br> <br>And thus the precedent for no underscore.<br>NT386MINGWIN ?<br>NT386MINGNU ?<br> <br>I don't know if "MSYS" needs a place in this name.<br>It is needed for building m3cc.<br> <br>I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise.<br> <br>Hint for anyone trying out Cygwin and getting an odd mix of paths:<br>mkdir \cygdrive<br>get junction.exe from the former <a
 href="http://www.sysinternals.com/" target="_blank">www.sysinternals.com</a><br>junction \cygdrive\c c:\<br>now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed.<br>If you have multiple drives, I guess just fully populate each one<br>c:\cygdrive\c => c:\<br>c:\cygdrive\d => d:\<br>d:\cygdrive\c => c:\<br>d:\cygdrive\d => d:\<br> <br>etc. but I haven't tried that.<br>Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc.<br> <br> - Jay<br><br><br> <hr id="EC_stopSpelling"> <br>> Date: Sun, 20 Jan 2008 15:56:49 +0100<br>> From: wagner@elegosoft.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br>> <br>> Quoting Jay <jayk123@hotmail.com>:<br>> <br>> > Good, a happy customer. :)<br>> ><br>> >> GNU_MODE = 0 % Do not use GNU tools at all
 -- today's NT386<br>> >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU<br>> >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably<br>> >> easy<br>> >><br>> >> Eh..I know, not great.. what do "minimally" and "maximally" mean.<br>> ><br>> > I'm still fishing for anyone to provide answers to these<br>> > less important decisions that I have trouble with.<br>> > Otherwise maybe no NT Cygwin system.<br>> ><br>> > TARGETs = { NT386, NT386GNU, NT386CYGWIN }?<br>> > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?<br>> > TARGETs = { NT386 + GNU_MODE }?<br>> ><br>> > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a <br>> > much larger jmpbuf than the others.<br>> > I think same TARGET implies code can be linked together, and I think <br>> > varying jmpbuf implies otherwise.<br>> > So NT386 and NT386MINGWIN
 should rarely cross paths with NT386CYGWIN.<br>> <br>> I think a new target is called for if I have understood everything right.<br>> We need one pure native target (NT386), one pure-Cygwin-based target<br>> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin<br>> (NT386_MINGWIN?).<br>> <br>> As NT386GNU already exists, we must decide if we want to use it as<br>> we traditionally did (all Cygwin) or the mixed implementation<br>> (Mingwin and much Windows RT).<br>> <br>> > I also do NOT like this ad-hoc naming style.<br>> > PPC_DARWIN, I386_DARWIN are much more to my style.<br>> > The names should be somehow hierarchical, except, I realize, there <br>> > isn't necessarily one "path" of<br>> > stuff which to name platforms, though the GNU folks have settled on <br>> > a way or two.<br>> > They have triples or quadruples -- processor-hardware-os or such, <br>> > however this
 doesn't<br>> > clearly suffice.<br>> <br>> Well, yes, something more systematic would have been better, but<br>> to break with the history will cause much trouble for all users and<br>> the infrastructure. So I'd rather vote that only new targets get<br>> more systematic names.<br>> <br>> > Something that accomodates:<br>> > NT386 + LLVM<br>> > NT386 + Watcom, linker and/or backend and/or runtime<br>> > NT386 + Digital Mars linker and/or backend and/or runtime<br>> > A C generating backend, and then linker/runtime<br>> > and similar IA64, AMD64 variants would be good.<br>> <br>> I'm not sure that a C generating backend would really help matters.<br>> This was done in the first implementation of DEC, and they soon<br>> abandoned it as C had proven to be a bad choice as intermediate language.<br>> I agree it would be great for cross-compilation etc.<br>> <br>> As far as C and RT dependencies of
 native Windows compilers go, I don't<br>> see why this couldn't be just a question of another cm3.cfg setup.<br>> <br>> > To a large extent, these can be few platforms, subject to <br>> > configuration, like if all<br>> > the linkers consume a common file format (not clear), and if all the <br>> > jmpbufs are the same<br>> > size (known to be partly true, partly false).<br>> <br>> Yes, jmpbuf is always a problem for user threads and exceptions.<br>> On Unix systems the jmpbuf and other important low-level structures<br>> are always defined by the system headers and independent of compilers<br>> AFAIK, so I'm a bit surprised that it should be different on Windows.<br>> But maybe I'm just wrong and haven't just seen the right counter<br>> examples...<br>> <br>> > Oh and another thing, the runtime dependency is very likely cuttable, however<br>> > PRESUMABLY real world applications (if there are any) link
 in a <br>> > substantial amount of<br>> > C or C++, in which case, it isn't necessarily cuttable.<br>> <br>> Yes. Real world applications tend to link other libraries (C, C++,<br>> Fortran, ...) and even often call other applications like sh etc.<br>> <br>> > As well, if I can figure out a good way to do it, switching NT386 <br>> > from awful slow<br>> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in <br>> > fs:0, that would be nice,<br>> > and might incur a C runtime dependency, but well worth it. The way <br>> > Modula-3 works here<br>> > is terrible. Another compromise option is probably <br>> > __declspec(thread), though there is trickiness there<br>> > in terms of being in a .dll that isn't used by the .exe.<br>> <br>> Such optimizations should be done depending on the target.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions
 GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <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="_blank">Play now!</a></blockquote><br>  <hr size="1"> <br><font face="Verdana" size="-2">Web Revelación Yahoo! 2007:<br>Premio Favorita del Público - <a href="http://es.promotions.yahoo.com/revelacion2007/favoritos/" target="_blank">¡Vota tu preferida!</a></font></blockquote><br><hr>Shed those extra pounds with MSN and The Biggest Loser! <a href="http://biggestloser.msn.com/" target="_new">Learn more.</a></blockquote><br><p>


      <hr size=1><br><font face="Verdana" size="-2">Web Revelación Yahoo! 2007:<br> Premio Favorita del Público - <a href="http://es.promotions.yahoo.com/revelacion2007/favoritos/">¡Vota tu preferida!</a></font>