I realize that these days you're all pretty much icons at AT&T Research, and we all know that's the only useful part of it left. But if I had to run these programs, I'd just run everything though a VM. A VM is not only portable but you can take snapshots of it and run it anywhere the VM host runs. What's really the point of this? I know that you folk wrote uwin and it's been useful to me, but sometimes you have to move on and find better pastures.
There's no way that I couldn't go into some place, given proper access, and sort this out with a VM, their choice of OSs. All of this dealing with Win8, Win7, WinXP, win this win that, it's a losing game. Except that you're icons at AT&T, what's to gain from this? > Send uwin-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.research.att.com/mailman/listinfo/uwin-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of uwin-users digest..." > > > Today's Topics: > > 1. Re: uwin-users Digest, Vol 98, Issue 5 (Irek Szczesniak) > 2. Re: uwin-users Digest, Vol 98, Issue 5 (Glenn Fowler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 May 2013 23:09:54 +0200 > From: Irek Szczesniak <[email protected]> > To: David Korn <[email protected]>, Glenn Fowler > <[email protected]> > Cc: [email protected] > Subject: Re: [uwin-users] uwin-users Digest, Vol 98, Issue 5 > Message-ID: > <CALnxO56gx_UTwxm3v-2EnsDBYUhLh=gtxp2jqddwd6-rdct...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, May 17, 2013 at 4:43 PM, Irek Szczesniak <[email protected]> > wrote: >> On Fri, May 17, 2013 at 3:07 PM, David Korn <[email protected]> >> wrote: >>> Subject: Re: Re: [uwin-users] uwin-users Digest, Vol 98, Issue 5 >>> -------- >>> >>>> my guess is the uwin fork/exec code would run afoul of wine's >>>> emulation >>>> that itself probably uses fork/exec and stands on its head trying to >>>> hide that >>> >>> I don't know why this would be a problem assuming that the WINE >>> emulation of CreateProcess() doesn't randomly lay out the address >>> space. >>> That means that two calls to CreateProcess() with the same arguments >>> should put shared libraries at the same address. >>> >>> UWIN uses only WIN32 calls so that if WINE implements WIN32 faithfully, >>> then in theory UWIN would work on WINE. >> >> Does posix.dll implement posix_spawn()? IMO a native posix_spawn() >> implementation would avoid the trouble of a fork(), exec() sequence > > Glenn? > > Irek > > > ------------------------------ > > Message: 2 > Date: Wed, 22 May 2013 17:23:41 -0400 > From: Glenn Fowler <[email protected]> > To: [email protected], [email protected], [email protected] > Cc: [email protected] > Subject: Re: [uwin-users] uwin-users Digest, Vol 98, Issue 5 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > On Wed, 22 May 2013 23:09:54 +0200 Irek Szczesniak wrote: >> On Fri, May 17, 2013 at 4:43 PM, Irek Szczesniak <[email protected]> >> wrote: >> > On Fri, May 17, 2013 at 3:07 PM, David Korn <[email protected]> >> wrote: >> >> Subject: Re: Re: [uwin-users] uwin-users Digest, Vol 98, Issue 5 >> >> -------- >> >> >> >>> my guess is the uwin fork/exec code would run afoul of wine's >> emulation >> >>> that itself probably uses fork/exec and stands on its head trying to >> hide that >> >> >> >> I don't know why this would be a problem assuming that the WINE >> >> emulation of CreateProcess() doesn't randomly lay out the address >> space. >> >> That means that two calls to CreateProcess() with the same arguments >> >> should put shared libraries at the same address. >> >> >> >> UWIN uses only WIN32 calls so that if WINE implements WIN32 >> faithfully, >> >> then in theory UWIN would work on WINE. >> > >> > Does posix.dll implement posix_spawn()? IMO a native posix_spawn() >> > implementation would avoid the trouble of a fork(), exec() sequence > >> Glenn? > > posix.dll provides spawnveg() with similar but limited semantics to > posix_spawn() > libast spawnvex() uses posix_spawn() or spawnveg() if possible > however fork() is required by ksh -- well ksh can run on non-fork systems > but its > not nearly as efficient -- dgk can provide more details on that > > > > ------------------------------ > > _______________________________________________ > uwin-users mailing list > [email protected] > http://lists.research.att.com/mailman/listinfo/uwin-users > > > End of uwin-users Digest, Vol 98, Issue 9 > ***************************************** > _______________________________________________ uwin-users mailing list [email protected] http://lists.research.att.com/mailman/listinfo/uwin-users
