Mail Archives: cygwin/2004/05/11/15:09:08
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/
- Raw text -