Yea, that would help a great deal. -----Original Message----- From: Nathan Laredo [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 3:08 PM To: [EMAIL PROTECTED]; Benson Margulies; [EMAIL PROTECTED] Subject: Re: Windows Server 2003 on AMD64 -- Making it work
Hi, If you simply want to get cygwin working on amd64 windows, create a cygwin.cmd in addition to your current C:\cygwin\cygwin.bat and make it do the following: @echo off C:\WINDOWS\SysWOW64\cmd.exe /c C:\cygwin\cygwin.bat Then, point your cygwin icon/shortcuts at cygwin.cmd and you'll be all set to go. I'm looking forward to the 64-bit native version of cygwin, but since the current version isn't it, you can make it work with the above wrapper script. You can then use the 32-bit cygwin to setup a 64-bit cross-compiling environment by rebuilding gcc/binutils/etc. I wish I had more time to spend on this. -- Nathan Laredo On Sun, Jan 18, 2004 at 07:37:56PM -0800, Tim Prince wrote: > At 10:12 AM 1/18/2004, Benson Margulies wrote: > > >TWIMC, > > > >Some time ago, I reported that fork() didn't work when running the > >current cygwin distro on the AMD64 on Windows. At the time, I > >debugged far enough to get an approximate picture of what Cygwin was > >doing with VirtualXXX calls to implement fork, and I posted some > >questions in the hopes of understanding it well enough to try to make > >a fix. As far as I could see, I didn't get a reply. > > > >To summarize, it seemed to me as if the code was making some > >assumptions about what virtual addresses ranges would be available > >and assigned under certain conditions related to fork, and that these > >assumptions were not valid on the AMD64, leading to failures. > > > >Presumably, a ground-rule of Cygwin is to program only to the > >documented Win32 API, and not to resort to the NT API substrate as > >illustrated in Nebbett. > > > >In any case, the offer is still open; if someone would be so kind as > >to offer up a summary of the design of fork(), I'd be willing to make > >some effort to diagnose and propose mods to adapt it. > > > > Since this hasn't been answered by more knowledgeable people, I'll > stick my > neck out. No, I don't believe anyone has found satisfactory support for > fork() within the documented Win32 API. Thus, cygwin is easily broken by > changes which Microsoft has made in the various "64-bit" Windows > versions. I do believe Cygwin has ground rules of running only on released > Windows versions for which cgf has been provided a working hardware > platform. If you're talking about the Physical Address Extension Windows > with 48-bit virtual/40-bit physical- addressing for AMD64, that meets > neither of those criteria. Apparently, no one has been willing to provide > any "64-bit" Windows hardware for the Cygwin project, even for the released > ia64 Windows. If you don't have more time than I to look at the source and > try to understand how fork() was implemented, I think you're wasting > bandwidth. Likewise, if you're proposing supporting a version of Windows > which Microsoft will not permit the Cygwin project to use. If you're > talking about standard released 32-bit Windows running on an AMD, my > impression is there should be no problem. > > > Tim Prince > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
