RE: Windows Server 2003 on AMD64 -- Making it work

["Benson Margulies" <bim2004 at basistech dot com>]

Yea, that would help a great deal.

-----Original Message-----
From: Nathan Laredo [mailto:nlaredo@transmeta.com] 
Sent: Tuesday, May 11, 2004 3:08 PM
To: cygwin@cygwin.com; Benson Margulies; tprince@computer.org
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/