Re: [Mingw-users] [wlestes@users.sourceforge.net: Re:[Flex-help][Flex-devel] fix compiler warning]

[Brian Dessent <brian@de...>]

John Brown wrote:

> You don't consider the need to be able to run 16-bit Windows and DOS
> apps to be a backwards compatibility headache? Maybe he would have

No, I don't.  You have to remember that NT as originally designed as a
modular system.  The part Cutler was designing, from what I understand,
was the privileged-mode side of things: HAL, device drivers, executive,
and kernel.  On top of that you have the various subsystems: Win32,
POSIX[1], OS/2.  But they ran for the most part as DLLs in user-space. 
>From the NT layer standpoint, it's mostly just supporting a number of OS
primitives: access control, devices, memory, IPC, etc. without any
specific notion of how they are going to be used by the subsystems.  And
this NT interface API was brand new without any backwards notion.

Plus for the 16 bit stuff, on NT it was all done with virtualization
(NTVDM), so again from the kernel view of things I don't think it really
had to know much about MS DOS or Win16, other than what was necessary to
implement real mode virtualization.

> like to do away with drive letters? I don't know, but I'm sure that there
> must be lots of things that he would have done differently if he were
> *really* starting from scratch.

Well technically the executive's object manager uses a flat namespace,
without any actual drive letters.  They are simply symlinks.  For
example, say you open c:\foo\bar.txt at the win32 level.  The Win32
subsystem translates this to the native path \??\c:\foo\bar.txt.  \?? is
itself kind of a symlink that allows for the fact that different
processes can be in different login sessions, and each login session can
have totally different drive mappings.  This symlink points to a
DosDevices directory that is local to that session.  In most cases
there's only one session and the global DosDevices directory (\GLOBAL??)
is used instead.

Inside these DosDevices dirs are symlinks for all the legacy names of
devices.  For example \DosDevices\C: might be a symlink to
\Device\HarddiskVolume1.  The same is true for all the legacy names,
e.g. \DosDevices\COM1 might be a symlink to \Device\Serial0.  And so
on.  The point is that at the NT level, drive letters don't really
exist.

Brian

[1] Note that processes cannot execute code across subsystem boundaries,
making the POSIX subsystem much less useful, as it's impossible to call
any Win32 code from a POSIX app.  So no Windows/desktop/interaction,
etc.

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help][Flex-devel] fix compiler warning]

[John Brown <johnbrown105@ho...>]

Brian Dessent wrote:
>
> ...
>
> If you think about that for a moment, Microsoft presented him with what
> nearly every software person dreams of: "You've already designed and
> maintained a large, successful, and robust operating system, now do it
> all over again but this time you can start from scratch without any
> backwards compatibility headaches, and you can apply everything you
> learned the first time around."
> ...
>
> Brian

This is not in anyway relevant to MinGW, and I don't know anything
about VMS, but:

You don't consider the need to be able to run 16-bit Windows and DOS
apps to be a backwards compatibility headache? Maybe he would have
like to do away with drive letters? I don't know, but I'm sure that there
must be lots of things that he would have done differently if he were
*really* starting from scratch.
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help][Flex-devel] fix compiler warning]

[Keith Marshall <keithmarshall@us...>]

On Friday 22 February 2008 20:10, Brian Dessent wrote:
[wrt VMS, and its legacy in Woe32]
>  "You've already designed and maintained a large, successful, and
>  robust operating system,

Well, this is very much a matter of personal opinion.  I've had the 
misfortune to have to maintain systems under VMS, and that wasn't fun.  
Thankfully, that dinosaur of an OS is now following the example of its 
biological forebears, in its progress into extinction.

> now do it all over again but this time you can start from scratch
> without any backwards compatibility headaches, and you can apply
> everything you learned the first time around."

And yes, I am well aware of the legacy of VMS in Woe32; much of the VMS 
nastiness has been inherited, (and yes, it is purely a matter of my 
personal opinion, that one of the nastiest of those features is its 
poor process management model).

Regards,
Keith.

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help][Flex-devel] fix compiler warning]

[Brian Dessent <brian@de...>]

Keith Marshall wrote:

> This just serves to illustrate how poorly the guys at Microsnot
> understand process management.  The only mitigating factor is that, in

Now that's just a ridiculous statement to make.  There's nothing that
says process management requires the ability to replace one process with
another.  It is nice to have if you have an intention to port software
that originates from the C/Unix tradition, but it is in no way
indicative of poor design, just different design.

And you can't blame this on Microsoft at all.  VMS worked in a very
similar way.  It had no true fork() but a vfork()-like thing wherein
calling fork() simply reserves space for a child process but does not
actually create one.  Control flow continues in the parent but with a
fork return value of 0, a codepath normally taken by the child.  This is
where you might typically close fd's or drop privileges before exec()ing
the child, but it's impossible here since this is still the parent. 
This state continues until exec() is called, at which point the  spawned
process is actually created and starts running.  Control in the parent
then jumps back to where fork() returned, but this time with the PID as
return value.

VMS does have the ability to replace a running process with another
without changing PIDs, but there is no way to pass command line
arguments.  There is a shared/common memory buffer area, and the two
processes can theoretically communicate arguments that way, but there's
no defined protocol so they'd both have to know to look there.  Thus
it's not a very useful and not recommended.

Anyway, the point here is that process management in VMS was always
designed in the "spawn new from scratch" mindset, not the "duplicate
then replace", exactly as Windows is today.  And that's no coincidence
because in 1988 when Microsoft was looking for an architect to lead the
design of their new NT operating system, they hired Dave Cutler from DEC
who was also the original architect of VMS.

If you think about that for a moment, Microsoft presented him with what
nearly every software person dreams of: "You've already designed and
maintained a large, successful, and robust operating system, now do it
all over again but this time you can start from scratch without any
backwards compatibility headaches, and you can apply everything you
learned the first time around."  Such a chance doesn't happen that often
- another example would be Dennis Ritchie and Plan 9 for Bell Labs.  I
guess what I'm getting at here is that Cutler is a pretty sharp guy and
to carry this aspect of process management over into NT would seem to
indicate that after all of those years of experience with VMS there was
no sense of inadequacy.

Brian

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help] [Flex-devel] fix compiler warning]

[Keith Marshall <keithmarshall@us...>]

On Friday 22 February 2008 07:53, Tor Lillqvist wrote:
> I wrote:
> >  > the execvp() in the Microsoft C library has slightly different
> >  > semantics than execvp() on Unix.
>
> Keith replied:
> > Except that Microsnot insist on adding an initial underscore in
> >  front of the name, (and claim that the undecorated name is
> > deprecated), there is fundamentally no syntactic difference.
>
> Well, I said semantics, not syntax.

Right.  I deliberately introduced the concept of `syntactic equivalence' 
to ensure that there would be no confusion over the subtle distinction 
with `semantic difference'.

> Isn't the fact that the exec'ed executable is run in a different
> process "slightly" different semantics?

Umm, no.  It's a hugely significant difference, with potentially 
catastrophic ramifications, of which I'm reminded by you posing this 
question.  Thanks.

> It tries to emulate true Unix-style exec by just exiting after
> starting the child process, without waiting for it, thus fulfilling
> the "never return" feature of exec, but I am sure there are situations
> in which this is not enough. 

Indeed.  Consider the scenario where process `foo' forks, to exec `bar', 
then waits for `bar' to complete; `bar' then subsequently execs `baz'.  
Any sane Unix programmer will expect `baz' to load its image into the 
same process, (with identical PID), as the child created by `foo'; 
hence `foo' will continue to wait until `baz' subsequently exits.  On 
Woe32, this doesn't behave as expected; `bar' creates a new distinct 
process, in which `baz' is execed, then quits.  At this point, `foo' 
knows nothing of the new child, for which it should continue to wait; 
it sees that `bar' has terminated, stops waiting, and `baz' becomes an 
orphaned process.

This just serves to illustrate how poorly the guys at Microsnot 
understand process management.  The only mitigating factor is that, in 
the most common scenario, (of exec being invoked to load a new image 
into the child branch of a forked process), the more appropriate Woe32 
function to use is one of the `spawn' family, rather than any of the 
`exec' family; this is clumsy, in comparison to `fork' ... `exec', but 
it can usually be coerced into delivering the correct behaviour.

Regards,
Keith.

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help]?[Flex-devel] fix compiler warning]

[John Brown <johnbrown105@ho...>]

On  Date: Fri, 22 Feb 2008 07:25:41 -0500, Bob Rossi wrote:
>
> On Thu, Feb 21, 2008 at 10:27:26PM +0000, Keith Marshall wrote:
>>
>> That's the codebase for the MSYS build of flex; it is dependent on
>> msys-1.0.dll, (which is a cygwin-1.3 derivative), and hence, can make
>> use of the Cygwin POSIX emulation layer, providing `fork' and friends.
>>
>> This implementation cannot live on native Woe32; it only works as a
>> component of MSYS.
>
> Huh, I guess I keep learning. Well, I don't mind compiling it for MSYS.

That would defeat your earlier stated objective which was:
"... to provide a patch back to the flex folks, so that flex builds
out-of-the-box on mingw."

_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help]?[Flex-devel] fix compiler warning]

[Earnie Boyd <earnie@us...>]

Quoting Bob Rossi <bob_rossi@...>:

>>
>> This implementation cannot live on native Woe32; it only works as a
>> component of MSYS.
>
> Huh, I guess I keep learning. Well, I don't mind compiling it for MSYS.
> Is that a totally different compiler or environment that I need to
> download? I currently only have the mingw compiler installed. (that I
> know of).
>

http://www.mingw.org/MinGWiki/index.php/MinGWHowTo

> Just out of curiosity. Why did MSYS decide to fork off of cygwin,
> instead of just use cygwin?
>

Just because.

The changes I did were too invasive to be accepted by Cygwin.  Chasing 
an ever changing product with your own changes can mean headaches 
before you even get your changes completed.  Including filters that are 
defined at build time is just as much a fork as a separate repository 
so I decided it was easier for the separate repository.

Earnie

Re: [Mingw-users] Bug with win32 fibers?

[Edd Dawson <lists@mr...>]

Ross Ridge wrote:
> Edd Dawson writes:
>> Out of interest, are there any nasty hacks that I could use to my library 
>> working with  SJLJ exceptions, or should I just forget the idea?
> 
> SJLJ don't work with fibers because when using this exception method GCC
> creates a linked list of exception frames for each thread.  Every time
> a try block is entered an exception frame is added to the list and when
> the block is exited the exception frame is removed.  Since each fiber
> running on the thread ends up using the same linked list this doesn't
> work if you switch fibers while inside of a try block.  You could use
> SJLJ exceptions in only one fiber and have it work, but otherwise I'd
> just forget the idea.
> 
> DWARF exceptions work in your example because when exceptions are thrown
> GCC unwinds the stack function by function using static exception
> records created at compile time for each function in the program.
> This should work with fibers, although it may not handle uncaught
> exceptions correctly.

Thank you, Ross. That was *incredibly* useful.

> You should also consider wether you really want to be using fibers.
> As Microsoft's documentation states they're only designed to make it
> easier to port code that does it's own thread scheduling.  They're not
> ment to be used in new code.

I'm implementing the boost thread API in terms of fibers (and 
getcontext/setcontext/makecontext/swapcontext on POSIX systems) for the purposes 
of debugging and testing threaded code. With only one real thread one can test 
algorithmic logic somewhat independently of synchronisation logic.

I don't plan to create applications that use fibers. This is just another tool 
in the box for debugging/testing my libraries and apps.

Kind regards,

Edd

Re: [Mingw-users] [wlestes@users.sourceforge.net:Re: [Flex-help]?[Flex-devel] fix compiler warning]

[Brian Dessent <brian@de...>]

Bob Rossi wrote:

> Huh, I guess I keep learning. Well, I don't mind compiling it for MSYS.
> Is that a totally different compiler or environment that I need to
> download? I currently only have the mingw compiler installed. (that I
> know of).

Yes, you need to install msysDVLPR which will includes an old version of
gcc 2.95.3 that identifies itself as i686-pc-msys.  And you need to set
MSYSTEM=MSYS so that MSYS will identify itself as such instead of
reporting that it is MinGW, which is what you normally want (i.e. using
MSYS to build MinGW apps.)

> Just out of curiosity. Why did MSYS decide to fork off of cygwin,
> instead of just use cygwin?

You can't "just use Cygwin" when you want to interoperate with native
tools, at least not easily.  The defining thing that differentiates the
two is that the MSYS runtime knows that when exec()ing e.g. "someapp.exe
--arg /usr/local/bin" it will see that someapp.exe is a native tool and
it will convert the /usr/local/bin argument to a native path like
c:/msys/1.0/usr/local/bin so that someapp.exe can remain totally
ignorant of what a POSIX path is or means.  Cygwin does no such
translation because it assumes you are always using POSIX tools.  You'd
have to explicitly know that someapp.exe can't grok POSIX paths and
explicitly invoke it as "someapp.exe --arg $(cygpath -m /usr/local/bin)"
which is obviously not a practical solution if you use lots of
someapp.exe's or you have a large build system or whatever.

There are other minor changes too: everything is binmode, there's no
textmode.  The mount table stored in a text file instead of the registry
and common mount points like / and /bin and /usr are auto-mounted based
on the location of msys-1.0.dll.  This means MSYS can usually be
installed simply with "tar xjf" and uninstalled with "rm -rf".  The only
thing you have to do is tell it the location of /mingw if it is not
actually in /.

Brian

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help]?[Flex-devel] fix compiler warning]

[Bob Rossi <bob_rossi@co...>]

On Thu, Feb 21, 2008 at 10:27:26PM +0000, Keith Marshall wrote:
> On Thursday 21 February 2008 22:05, Bob Rossi wrote:
> > > > OK, I looked on sf, it looks like the pipe,fork stuff is in the
> > > > src. How was this ever compiled in the first place?
> > >
> > > What code are you looking at? I can't see any of this stuff on the
> > > GnuWin32 flex 2.5.4a
> > > (http://gnuwin32.sourceforge.net/packages/flex.htm).
> >
> > http://sourceforge.net/project/showfiles.php?group_id=2435
> > Search for "flex".
> 
> That's the codebase for the MSYS build of flex; it is dependent on 
> msys-1.0.dll, (which is a cygwin-1.3 derivative), and hence, can make 
> use of the Cygwin POSIX emulation layer, providing `fork' and friends.
> 
> This implementation cannot live on native Woe32; it only works as a 
> component of MSYS.

Huh, I guess I keep learning. Well, I don't mind compiling it for MSYS.
Is that a totally different compiler or environment that I need to
download? I currently only have the mingw compiler installed. (that I
know of).

Just out of curiosity. Why did MSYS decide to fork off of cygwin,
instead of just use cygwin?

Thanks,
Bob Rossi

Re: [Mingw-users] A mingw compiled program using pthread crashes under windows

[Tor Lillqvist <tml@ik...>]

>  found the installation line "install
>  -m664 libpthreadGC2.a "$PREFIX/$TARGET/lib/libpthread.a", so my
>  libpthread.a is obviously the one you meant before nuder a different name.

OK. (That is actually what I have done too, copied libpthreadGC2.a to
libpthread.dll.a so that I don't have to modify Makefiles that just
use -lpthread .

>  What is the pthreadGCE2 library you mentioned before?

Read the README in pthreads-win32. The "GC2" version is for GNU
compilers, no exception handling involved, pthreads-win32 version 2.
"GCE2" is for GNU compilers, C++ exception handling, pthreads-win32
version 2.

Anyway, I couldn't reproduce the crash with the 2.8.0 version either.

> installs a cross compiling enviroment (unsig, among others,
> mingw-runtime 3.14, gcc 4.2.1-2, binutils 2.18.50  and w32api 3.11)

I use gcc 3.4.5 (and binutils 2.17.50). That might be significant.
Perhaps if you recompiled pthreads-win32 from sources with your
toolchain it would work better? (If you do this, for your own sanity,
use a different name unique to you for the pthreads DLL you produce to
avoid potential confusion.)

--tml

Re: [Mingw-users] A mingw compiled program using pthread crashes under windows

[Mathias Tausig <mtausig@fs...>]

>> Oops, I forgot the version information. I use the latest mingw build
>> using
>>  pthreads-win32-2.8.0 and nothing else.
>
> Sorry, but exactly what do you mean with this? Where from did you
> download this pthreads-win32-2.8.0?

I am using the build_mingw_cross_env.sh (1.4) that automatically downloads
builds and installs a cross compiling enviroment (unsig, among others,
mingw-runtime 3.14, gcc 4.2.1-2, binutils 2.18.50  and w32api 3.11) and in
this course also downloads pthreads-w32-2.8.0 from sourceware.org.
I just lokked through the script and found the installation line "install
-m664 libpthreadGC2.a "$PREFIX/$TARGET/lib/libpthread.a", so my
libpthread.a is obviously the one you meant before nuder a different name.
What is the pthreadGCE2 library you mentioned before?

cheers
mathias
>
>> So no cygwin that I am aware of.
>
> OK, good.
>
>>  But yes, I link against the libpthread.a, which is the only pthread
>> library to be
>>  found in my mingw lib dir, the two libs you are stating were obviously
>> not
>>  automatically built by the mingw installer. Did you install them
>> manually?
>
> I wasn't aware that mingw shipped pthreads-win32. I have
> mingw-runtime-3.14 and I don't see any libpthread.a there. I also
> don't see any separate pthreads packages while surfing around
> http://sourceforge.net/project/showfiles.php?group_id=2435 . Am I
> missing something? (I installed my mingw stuff from the tarballs. Do
> the executable installers have more stuff, like a bundled
> pthreads-win32?)
>
> I use pthreads-win32 from http://sourceware.org/pthreads-win32/ . In
> there, for instance in
> ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib , there is no
> libpthread.a.
>
> --tml
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>

Re: [Mingw-users] A mingw compiled program using pthread crashes under windows

[Tor Lillqvist <tml@ik...>]

> Oops, I forgot the version information. I use the latest mingw build using
>  pthreads-win32-2.8.0 and nothing else.

Sorry, but exactly what do you mean with this? Where from did you
download this pthreads-win32-2.8.0?

> So no cygwin that I am aware of.

OK, good.

>  But yes, I link against the libpthread.a, which is the only pthread library to be
>  found in my mingw lib dir, the two libs you are stating were obviously not
>  automatically built by the mingw installer. Did you install them manually?

I wasn't aware that mingw shipped pthreads-win32. I have
mingw-runtime-3.14 and I don't see any libpthread.a there. I also
don't see any separate pthreads packages while surfing around
http://sourceforge.net/project/showfiles.php?group_id=2435 . Am I
missing something? (I installed my mingw stuff from the tarballs. Do
the executable installers have more stuff, like a bundled
pthreads-win32?)

I use pthreads-win32 from http://sourceware.org/pthreads-win32/ . In
there, for instance in
ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib , there is no
libpthread.a.

--tml

Re: [Mingw-users] [wlestes@users.sourceforge.net: Re: [Flex-help] [Flex-devel] fix compiler warning]

[Tor Lillqvist <tml@ik...>]

I wrote:
>  > the execvp() in the Microsoft C library has slightly different
>  > semantics than execvp() on Unix.

Keith replied:
> Except that Microsnot insist on adding an initial underscore in
>  front of the name, (and claim that the undecorated name is deprecated),
>  there is fundamentally no syntactic difference.

Well, I said semantics, not syntax. Isn't the fact that the exec'ed
executable is run in a different process "slightly" different
semantics? It tries to emulate true Unix-style exec by just exiting
after starting the child process, without waiting for it, thus
fulfilling the "never return" feature of exec, but I am sure there are
situations in which this is not enough.

--tml