From ssiddiqi@inspirepharm.com Mon Jul 5 07:36:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Mon, 05 Jul 1999 07:36:00 -0000 Subject: Update Message-ID: This to let cygwin-xfree users know: For a while this list has been inactive. We have not given up on development of cygwin-xfree. A couple of major cygwin-xfree contributors are unable to devote enough time recently; due to some personal matters and/or summer vacations. Hopefully in a few weeks they will be able to spend more time on cygwin-xfree projects. Suhaib From ssiddiqi@inspirepharm.com Sun Jul 11 06:39:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 06:39:00 -0000 Subject: Glide/X Message-ID: Update on cygwin-xfree. Mumit helped to fix Glide DLLs problems. Therefore credit goes to him getting Glide compiled under Cygwin. I compiled the x-server whch uses Glide/3Dfx accelaration for 3Dfx/Voodoo cards. However, there are still some serious display bugs in X-server code, which needs to be fixed. On startup it blinks on the screen then core dumps with error messages *cannot find visual (glide) display*. I need to contact 3Dfx for permission for releasing the 3Dfx/Glide SDK for Cygwin. Historically they had always given to anyone who asked for it. Their license required to obtain permission if developers intend to redistribute the altered 3Dfx/Glide SDK. John Fortin is working a DirectX target for cygwin-xfree and Carl intends to write a traditional style GDI for X, like Hummingbird. We are making progress, though mailing list for cygwin-xfree had been some what inactive for a while. Suhaib From ssiddiqi@inspirepharm.com Sun Jul 11 09:37:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 09:37:00 -0000 Subject: dlopen error Message-ID: Mumit once mentioned that dlopn error is a bug in Cygwin. Anyone has any suggestions on a wrokaround for the following problem? When I satrt X-server for Glide, I get dlopen error *unable to open lib: dlopen: Win32 error 127*. The dll is in path. libGGI finds it and reports the correct path:/usr/local/lib/ggi\display/glide-0-0-0.dll, but still returns the dlopen failure. Suhaib bash-2.02$ LibGII: Debugging=255 LibGGI: Debugging=255 LibGGI: ggiOpen("glide") called LibGGI: Loading driver glide LibGGI: _ggiAddDL(0x10070fb8, "glide", "(null)", 0x1) called LibGGI: _ggiLoadDL("/usr/local/lib/ggi\display/glide-0-0-0.dll", 0x1) called LibGG: unable to open lib: dlopen: Win32 error 127 LibGGI: hand.handle=0x0 LibGGI: Error loading module /usr/local/lib/ggi\display/glide-0-0-0.dll LibGGI: _ggiLoadDL returned 0x0 LibGGI: ggiOpen: failure Fatal server error: Unable to open LibGGI visual: "glide" LibGGI: ggiExit called LibGGI: ggiExit: really destroying. LibGII: giiExit() called LibGII: giiExit: really destroying. LibGII: giiExit: done! LibGGI: ggiExit: done! [1]+ Exit 1 ./xggi -targets glide bash-2.02$ ps PID TTY STIME COMMAND 1000 -1 12:22:48 /e/pgi/cygusr/H-I586~1/bin/bash.exe 1005 -1 12:24:26 /e/pgi/cygusr/H-I586~1/bin/ps.exe bash-2.02$ From khan@xraylith.wisc.EDU Sun Jul 11 10:46:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 11 Jul 1999 10:46:00 -0000 Subject: dlopen error References: Message-ID: <199907111746.MAA29053@mercury.xraylith.wisc.edu> "Suhaib M. Siddiqi" writes: > Mumit once mentioned that dlopn error is a bug in Cygwin. There are two separate set of bugs in dlopen: - pathname searching -- fixed in b20.1 (see ChangeLog entries for dlfcn.cc:get_dll_full_pathname()) - fork doesn't reload dlopen'd libraries due to a small error. Will be fixed next release. I doubt if either is responsible for your problem below. > Anyone has any suggestions on a wrokaround for the following problem? > When I satrt X-server for Glide, I get dlopen error *unable to open lib: > dlopen: Win32 error 127*. > The dll is in path. libGGI finds it and reports the correct > path:/usr/local/lib/ggi\display/glide-0-0-0.dll, but still returns the > dlopen failure. > > Suhaib > > bash-2.02$ LibGII: Debugging=255 > LibGGI: Debugging=255 > LibGGI: ggiOpen("glide") called > LibGGI: Loading driver glide > LibGGI: _ggiAddDL(0x10070fb8, "glide", "(null)", 0x1) called > LibGGI: _ggiLoadDL("/usr/local/lib/ggi\display/glide-0-0-0.dll", 0x1) called > LibGG: unable to open lib: dlopen: Win32 error 127 This means "The specified function cannot be found" or some such thing. I love these descriptive error codes ;-) I'm appending a simple program that will translate error codes for you. Just compile and run error code(s) as command line arguments. I suggest the following: write a trivial 5-liner that dlopen's the glide-0-0-dll. If successful, we'll look further; if not, then we have a problem with either the entry point or any of the other dozens or so things that can go wrong. I haven't paid much attention the DLL building code in ggi (via libtool); I'll do so today and take a look. My suspicion is in the DllMain is done, but I may be way off. BTW, can you make sure that all the dependent DLLs for ggi-0-0-0.dll are in your PATH or in the same directory as ggi-*.dll? To find dependent DLLs: $ objdump -p ggi-0-0-0.dll | grep "DLL Name" Run with STRACE=1,foo.out and see what foo.out says. Regards, Mumit === cut from here to end. /* * win32-errmsg: Translate win32 error codes to text messages. * * Usage: win32-errmsg [error-code [error-code ...]] * */ #include #include #include #include void format_error (char *msg, int msglen, int errnum) { if (FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, errnum, MAKELANGID (LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR) msg, msglen, NULL)) { msg [strlen (msg) - 2] = '\0'; } else { sprintf (msg, "Win32 error %d", errnum); } } int main (int argc, char *argv[]) { int i; for (i = 1; i < argc; i++) { int errnum = atoi (argv[i]); char msg[256]; sprintf (msg, "%s (Error %d): ", argv[0], errnum); format_error (msg + strlen (msg), sizeof (msg) - strlen (msg), errnum); puts (msg); } return 0; } From khan@xraylith.wisc.EDU Sun Jul 11 11:09:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 11 Jul 1999 11:09:00 -0000 Subject: dlopen error References: Message-ID: <199907111809.NAA29123@mercury.xraylith.wisc.edu> "Suhaib M. Siddiqi" writes: > Mumit once mentioned that dlopn error is a bug in Cygwin. > Anyone has any suggestions on a wrokaround for the following problem? > When I satrt X-server for Glide, I get dlopen error *unable to open lib: > dlopen: Win32 error 127*. > The dll is in path. libGGI finds it and reports the correct > path:/usr/local/lib/ggi\display/glide-0-0-0.dll, but still returns the > dlopen failure. Here's a quick test program to see if you can load ggi-0-0-0.dll using dlopen succesfully. Run it with the full pathname as in ggi does and see what happens. Another problem is all the DLLs are based at default 0x10000000, and causes relocation all over the place. I added code dllwrap precisely because of this to use the output filename as a hash key and generate a base address (if not user specified of course) to avoid this relocation and resultant excessive copying by windows32 loader. You'll need to at some point build the whole thing with -g and run it under gdb. No easy way, sorry. #include #include #include #include /* see comment about 2nd arg to dlopen on Cygwin. */ #ifndef RTLD_GLOBAL # define RTLD_GLOBAL 0 #endif int main (int argc, char *argv[]) { void *dll_handle; char *dllname; if (argc != 2) { fprintf (stderr, "Usage: %s dll-name\n", argv[0]); return 1; } dllname = argv[1]; printf ("PATH = %s\n", getenv ("PATH")); /* the second arg is ignored on Cygwin, here for exposition only. */ dll_handle = dlopen (dllname, RTLD_LAZY | RTLD_GLOBAL); if (! dll_handle) { fprintf (stderr, "%s\n", dlerror ()); return 1; } printf ("Success: DLL handle %x\n", dll_handle); dlclose (dll_handle); return 0; } From ssiddiqi@inspirepharm.com Sun Jul 11 11:25:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 11:25:00 -0000 Subject: dlopen error References: <199907111809.NAA29123@mercury.xraylith.wisc.edu> Message-ID: Mumit, Thank very much for your help. I ran your dlopen Test. I get error. But I am not sure about it because it give dlopen:Win32 error 127. When I check the error 127 using your dll error check code, I get *./dllerror (Error 127): The specified procedure could not be found.* I tried it on the DLLs from GGI I know gets opened. They return error 126, That is specified module could not be found.* Does it mean glide-0-0-0.dll cannot find a procedure specified in the glide code? Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mumit Khan > Sent: Sunday, July 11, 1999 2:10 PM > To: Suhaib M. Siddiqi > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: Re: dlopen error > > > "Suhaib M. Siddiqi" writes: > > Mumit once mentioned that dlopn error is a bug in Cygwin. > > Anyone has any suggestions on a wrokaround for the following problem? > > When I satrt X-server for Glide, I get dlopen error *unable to open lib: > > dlopen: Win32 error 127*. > > The dll is in path. libGGI finds it and reports the correct > > path:/usr/local/lib/ggi\display/glide-0-0-0.dll, but still returns the > > dlopen failure. > > Here's a quick test program to see if you can load ggi-0-0-0.dll using > dlopen succesfully. Run it with the full pathname as in ggi does and > see what happens. > > Another problem is all the DLLs are based at default 0x10000000, and > causes relocation all over the place. I added code dllwrap precisely > because of this to use the output filename as a hash key and generate > a base address (if not user specified of course) to avoid this relocation > and resultant excessive copying by windows32 loader. > > You'll need to at some point build the whole thing with -g and run it > under gdb. No easy way, sorry. > > #include > #include > #include > #include > > /* see comment about 2nd arg to dlopen on Cygwin. */ > #ifndef RTLD_GLOBAL > # define RTLD_GLOBAL 0 > #endif > > int > main (int argc, char *argv[]) > { > void *dll_handle; > char *dllname; > if (argc != 2) > { > fprintf (stderr, "Usage: %s dll-name\n", argv[0]); > return 1; > } > dllname = argv[1]; > > printf ("PATH = %s\n", getenv ("PATH")); > > /* the second arg is ignored on Cygwin, here for exposition only. */ > dll_handle = dlopen (dllname, RTLD_LAZY | RTLD_GLOBAL); > if (! dll_handle) > { > fprintf (stderr, "%s\n", dlerror ()); > return 1; > } > > printf ("Success: DLL handle %x\n", dll_handle); > dlclose (dll_handle); > return 0; > } > > From ssiddiqi@inspirepharm.com Sun Jul 11 11:38:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 11:38:00 -0000 Subject: dlopen error References: <199907111809.NAA29123@mercury.xraylith.wisc.edu> Message-ID: Ok, now when I ran objdump I get the listing. DLL Name" DLL Name: libgg-0-0-6.dll DLL Name: libggi-2-0-0.dll DLL Name: libgii-0-0-6.dll DLL Name: cygwin1.dll DLL Name: Glide2x.dll DLL Name: kernel32.dll So what I did I copied all these DLLs into the same directory where glide-0-0-0.dll is. Now the error message changed from 127 to 12, i.e The specified module could not be found. I do not which other module it is searching. This a Windows NT, machine with Banshee/Voodoo card and its drivers installed. Therefore, hardware cannot be an issue. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mumit Khan > Sent: Sunday, July 11, 1999 2:10 PM > To: Suhaib M. Siddiqi > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: Re: dlopen error > > > "Suhaib M. Siddiqi" writes: > > Mumit once mentioned that dlopn error is a bug in Cygwin. > > Anyone has any suggestions on a wrokaround for the following problem? > > When I satrt X-server for Glide, I get dlopen error *unable to open lib: > > dlopen: Win32 error 127*. > > The dll is in path. libGGI finds it and reports the correct > > path:/usr/local/lib/ggi\display/glide-0-0-0.dll, but still returns the > > dlopen failure. > > Here's a quick test program to see if you can load ggi-0-0-0.dll using > dlopen succesfully. Run it with the full pathname as in ggi does and > see what happens. > > Another problem is all the DLLs are based at default 0x10000000, and > causes relocation all over the place. I added code dllwrap precisely > because of this to use the output filename as a hash key and generate > a base address (if not user specified of course) to avoid this relocation > and resultant excessive copying by windows32 loader. > > You'll need to at some point build the whole thing with -g and run it > under gdb. No easy way, sorry. > > #include > #include > #include > #include > > /* see comment about 2nd arg to dlopen on Cygwin. */ > #ifndef RTLD_GLOBAL > # define RTLD_GLOBAL 0 > #endif > > int > main (int argc, char *argv[]) > { > void *dll_handle; > char *dllname; > if (argc != 2) > { > fprintf (stderr, "Usage: %s dll-name\n", argv[0]); > return 1; > } > dllname = argv[1]; > > printf ("PATH = %s\n", getenv ("PATH")); > > /* the second arg is ignored on Cygwin, here for exposition only. */ > dll_handle = dlopen (dllname, RTLD_LAZY | RTLD_GLOBAL); > if (! dll_handle) > { > fprintf (stderr, "%s\n", dlerror ()); > return 1; > } > > printf ("Success: DLL handle %x\n", dll_handle); > dlclose (dll_handle); > return 0; > } > > From khan@xraylith.wisc.EDU Sun Jul 11 12:21:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 11 Jul 1999 12:21:00 -0000 Subject: dlopen error References: Message-ID: <199907111921.OAA29216@mercury.xraylith.wisc.edu> "Suhaib M. Siddiqi" writes: > > Ok, now when I ran objdump I get the listing. > > DLL Name" > DLL Name: libgg-0-0-6.dll > DLL Name: libggi-2-0-0.dll > DLL Name: libgii-0-0-6.dll > DLL Name: cygwin1.dll > DLL Name: Glide2x.dll > DLL Name: kernel32.dll > > So what I did I copied all these DLLs into the same directory where > glide-0-0-0.dll is. Now the error message changed from 127 to 12, i.e > The specified module could not be found. > I do not which other module it is searching. > This a Windows NT, machine with Banshee/Voodoo card and its drivers > installed. Therefore, hardware cannot be an issue. But each of these can be dependent on other DLLs that your machine may not have. The one in particular is DDRAW.DLL, which I know nothing about but needed by GLIDE2X.DLL. That's why I suggested using the debugger which prints out the various DLLs as they're being loaded. You can run `objdump -p | grep "DLL Name"' on the DLLs as well to see what they depend on. Please make sure your system has *ALL* these DLLs: glide-0-0-0.dll libgg-0-0-6.dll libggi-2-0-0.dll libgii-0-0-6.dll GLIDE2X.DLL DDRAW.dll << system dll when you try to open glide-0-0-0.dll. Build dlopen-test.exe with debugging (-g), and run it under gdb. $ gdb dlopen-test (gdb) b main (gdb) run glide-0-0-0.dll when it stops in main, step (using 'n') until you hit the call to dlopen. As soon you go past dlopen, gdb will print messages regarding loading these DLLs, and you may get more information that you. I see the following for example (and it tells me that the loading was successful): 26 dll_handle = dlopen (dllname, RTLD_LAZY | RTLD_GLOBAL); (gdb) n 1a150000:d:\src\x11-stuff\dlopen-test\glide-0-0-0.dll 1a1c0000:d:\src\x11-stuff\dlopen-test\libgg-0-0-6.dll 1a220000:d:\src\x11-stuff\dlopen-test\libggi-2-0-0.dll warning: LDR: Automatic DLL Relocation in dlopen-test.exe warning: LDR: Dll glide-0-0-0.dll base 10000000 relocated due to collision with Dynamically Allocated Memory warning: LDR: Automatic DLL Relocation in dlopen-test.exe warning: LDR: Dll libgg-0-0-6.dll base 10000000 relocated due to collision with Dynamically Allocated Memory warning: LDR: Automatic DLL Relocation in dlopen-test.exe warning: LDR: Dll libggi-2-0-0.dll base 10000000 relocated due to collision with Dynamically Allocated Memory 1a290000:d:\src\x11-stuff\dlopen-test\libgii-0-0-6.dll 1a2f0000:d:\src\x11-stuff\dlopen-test\GLIDE2X.DLL 77130000:C:\WINNT\System32\DDRAW.dll warning: LDR: Automatic DLL Relocation in dlopen-test.exe warning: LDR: Dll libgii-0-0-6.dll base 10000000 relocated due to collision with Dynamically Allocated Memory warning: LDR: Automatic DLL Relocation in dlopen-test.exe warning: LDR: Dll GLIDE2X.DLL base 10000000 relocated due to collision with Dynamically Allocated Memory [failed reading symbols from DLL] "C:\WINNT\System32\WINMM.dll": error reading line numbers [failed reading symbols from DLL] "C:\WINNT\System32\mmdrv.dll": error reading line numbers (gdb) print dll_handle $1 = (void *) 0x1a150000 I've cleaned up the gdb output a bit. Regards, Mumit From fortinj@ibm.net Sun Jul 11 14:05:00 1999 From: fortinj@ibm.net (John Fortin) Date: Sun, 11 Jul 1999 14:05:00 -0000 Subject: dlopen error References: <199907111921.OAA29216@mercury.xraylith.wisc.edu> Message-ID: <3789085C.7FBECDEE@ibm.net> All, ddraw.dll is from DirectX. John Mumit Khan wrote: > > "Suhaib M. Siddiqi" writes: > > > > Ok, now when I ran objdump I get the listing. > > > > DLL Name" > > DLL Name: libgg-0-0-6.dll > > DLL Name: libggi-2-0-0.dll > > DLL Name: libgii-0-0-6.dll > > DLL Name: cygwin1.dll > > DLL Name: Glide2x.dll > > DLL Name: kernel32.dll > > > > So what I did I copied all these DLLs into the same directory where > > glide-0-0-0.dll is. Now the error message changed from 127 to 12, i.e > > The specified module could not be found. > > I do not which other module it is searching. > > This a Windows NT, machine with Banshee/Voodoo card and its drivers > > installed. Therefore, hardware cannot be an issue. > > But each of these can be dependent on other DLLs that your machine may > not have. The one in particular is DDRAW.DLL, which I know nothing about > but needed by GLIDE2X.DLL. That's why I suggested using the debugger > which prints out the various DLLs as they're being loaded. You can run > `objdump -p | grep "DLL Name"' on the DLLs as well to see what they > depend on. Please make sure your system has *ALL* these DLLs: > > glide-0-0-0.dll > libgg-0-0-6.dll > libggi-2-0-0.dll > libgii-0-0-6.dll > GLIDE2X.DLL > DDRAW.dll << system dll > > when you try to open glide-0-0-0.dll. > > Build dlopen-test.exe with debugging (-g), and run it under gdb. > > $ gdb dlopen-test > (gdb) b main > (gdb) run glide-0-0-0.dll > > when it stops in main, step (using 'n') until you hit the call to dlopen. > As soon you go past dlopen, gdb will print messages regarding loading these > DLLs, and you may get more information that you. I see the following for > example (and it tells me that the loading was successful): > > 26 dll_handle = dlopen (dllname, RTLD_LAZY | RTLD_GLOBAL); > (gdb) n > 1a150000:d:\src\x11-stuff\dlopen-test\glide-0-0-0.dll > 1a1c0000:d:\src\x11-stuff\dlopen-test\libgg-0-0-6.dll > 1a220000:d:\src\x11-stuff\dlopen-test\libggi-2-0-0.dll > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll glide-0-0-0.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll libgg-0-0-6.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll libggi-2-0-0.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > 1a290000:d:\src\x11-stuff\dlopen-test\libgii-0-0-6.dll > 1a2f0000:d:\src\x11-stuff\dlopen-test\GLIDE2X.DLL > 77130000:C:\WINNT\System32\DDRAW.dll > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll libgii-0-0-6.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll GLIDE2X.DLL base 10000000 relocated due to > collision with Dynamically Allocated Memory > > [failed reading symbols from DLL] > "C:\WINNT\System32\WINMM.dll": error reading line numbers > > [failed reading symbols from DLL] > "C:\WINNT\System32\mmdrv.dll": error reading line numbers > > (gdb) print dll_handle > $1 = (void *) 0x1a150000 > > I've cleaned up the gdb output a bit. > > Regards, > Mumit From ssiddiqi@inspirepharm.com Sun Jul 11 14:23:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 14:23:00 -0000 Subject: dlopen error References: <199907111921.OAA29216@mercury.xraylith.wisc.edu> Message-ID: Mumit, I noticed, glide-0-0-0.dll on your system is pulling DDRAW.DLL too? I do not have DDRAW.DLL. It is actually DirectDraw/DirectX DLL, as John pointed out. I do not have DirectX installed. On NT 4.0 newer versions of DirectDraw/DirectX are not supported. That is why I never installed DirectD/DirectX. When you patched 3Dfx headers and created the implib for Glide, could it be possible that it got linked to DDRAW too? I cannot see that though under objdump. All the DLLs from GGI get opened, except glide-0-0-0.dll. I also compiled today terminfo-0-0-0.dll of GGI. terminfo does display using simple stdin/stdout. It was a good decision, because that helped me find a new bug in libX11.dll, which I did not notice until now. I will work on your suggestions. Right now I am recompiling X11 libs after doing the patch for the bug I discovered today. I haev seen the Dlls locations under gdb. I did not give it a priority to fix, may be I should because of glide.dll problem. Regards Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mumit Khan > Sent: Sunday, July 11, 1999 3:21 PM > To: Suhaib M. Siddiqi > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: Re: dlopen error > > > "Suhaib M. Siddiqi" writes: > > > > Ok, now when I ran objdump I get the listing. > > > > DLL Name" > > DLL Name: libgg-0-0-6.dll > > DLL Name: libggi-2-0-0.dll > > DLL Name: libgii-0-0-6.dll > > DLL Name: cygwin1.dll > > DLL Name: Glide2x.dll > > DLL Name: kernel32.dll > > > > So what I did I copied all these DLLs into the same directory where > > glide-0-0-0.dll is. Now the error message changed from 127 to 12, i.e > > The specified module could not be found. > > I do not which other module it is searching. > > This a Windows NT, machine with Banshee/Voodoo card and its drivers > > installed. Therefore, hardware cannot be an issue. > > But each of these can be dependent on other DLLs that your machine may > not have. The one in particular is DDRAW.DLL, which I know nothing about > but needed by GLIDE2X.DLL. That's why I suggested using the debugger > which prints out the various DLLs as they're being loaded. You can run > `objdump -p | grep "DLL Name"' on the DLLs as well to see what they > depend on. Please make sure your system has *ALL* these DLLs: > > glide-0-0-0.dll > libgg-0-0-6.dll > libggi-2-0-0.dll > libgii-0-0-6.dll > GLIDE2X.DLL > DDRAW.dll << system dll > > when you try to open glide-0-0-0.dll. > > Build dlopen-test.exe with debugging (-g), and run it under gdb. > > $ gdb dlopen-test > (gdb) b main > (gdb) run glide-0-0-0.dll > > when it stops in main, step (using 'n') until you hit the call to dlopen. > As soon you go past dlopen, gdb will print messages regarding > loading these > DLLs, and you may get more information that you. I see the following for > example (and it tells me that the loading was successful): > > 26 dll_handle = dlopen (dllname, RTLD_LAZY | RTLD_GLOBAL); > (gdb) n > 1a150000:d:\src\x11-stuff\dlopen-test\glide-0-0-0.dll > 1a1c0000:d:\src\x11-stuff\dlopen-test\libgg-0-0-6.dll > 1a220000:d:\src\x11-stuff\dlopen-test\libggi-2-0-0.dll > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll glide-0-0-0.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll libgg-0-0-6.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll libggi-2-0-0.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > 1a290000:d:\src\x11-stuff\dlopen-test\libgii-0-0-6.dll > 1a2f0000:d:\src\x11-stuff\dlopen-test\GLIDE2X.DLL > 77130000:C:\WINNT\System32\DDRAW.dll > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll libgii-0-0-6.dll base 10000000 relocated due to > collision with Dynamically Allocated Memory > > warning: LDR: Automatic DLL Relocation in dlopen-test.exe > > warning: LDR: Dll GLIDE2X.DLL base 10000000 relocated due to > collision with Dynamically Allocated Memory > > > [failed reading symbols from DLL] > "C:\WINNT\System32\WINMM.dll": error reading line numbers > > > [failed reading symbols from DLL] > "C:\WINNT\System32\mmdrv.dll": error reading line numbers > > (gdb) print dll_handle > $1 = (void *) 0x1a150000 > > I've cleaned up the gdb output a bit. > > Regards, > Mumit > From khan@xraylith.wisc.EDU Sun Jul 11 14:53:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 11 Jul 1999 14:53:00 -0000 Subject: dlopen error References: Message-ID: <199907112153.QAA29977@mercury.xraylith.wisc.edu> "Suhaib M. Siddiqi" writes: > > I noticed, glide-0-0-0.dll on your system is pulling DDRAW.DLL too? > I do not have DDRAW.DLL. It is actually DirectDraw/DirectX DLL, as > John pointed out. I do not have DirectX installed. On NT 4.0 newer > versions of DirectDraw/DirectX are not supported. That is why I never > installed DirectD/DirectX. When you patched 3Dfx headers and created > the implib for Glide, could it be possible that it got linked to > DDRAW too? I cannot see that though under objdump. All the DLLs from GGI > get opened, except glide-0-0-0.dll. I also compiled today > terminfo-0-0-0.dll of GGI. terminfo does display using simple stdin/stdout. > It was a good decision, because that helped me find a new bug in libX11.dll, > which I did not notice until now. The Glide SDK DLL itself depends on DDRAW.DLL, and nothing you or I do will change that. Sorry. Do an objdump on the Glide SDK DLL and you'll see. I don't know how I have DDRAW.DLL on this NT machine that I use for testing our own software, and don't even remember installing DirectDraw. Perhaps some other software installed it. Regards, Mumit From ssiddiqi@inspirepharm.com Sun Jul 11 15:32:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 15:32:00 -0000 Subject: Xggi/glide References: Message-ID: > > > > I just remembered that -mpentium was once causing problems to > me. I forgot > > to > > remove -mpentium from xfree86site.def file. I just removed it from > > cygwin.cf file and trying to recompile. If it fails again then I will > > run -save-temp > > and send you out put. > > Thanks for your help. > > Ah, yes, that's a bug. I believe it's fixed in gcc-2.95. > > I just rebuilt all the gii/ggi stuff so that all the DLLs have different > image base addresses. If you want those, let me know. I will need to build them here too. Can you send me the changes you did for image base addresses, please. I have did a lot of chnages to X11 stuff this weekend. It will not affect libraries though. All the changes were done in xc/programs/Xserver and its subdirectories. basically pacthing up to remove more Linux kernel header related stuff from Xserver directory. Suhaib > > I've also made changes to how the DLLs are built, but that's probably > not important in your case since the current setup seems to work. > > Regards, > Mumit > > From fortinj@ibm.net Sun Jul 11 16:25:00 1999 From: fortinj@ibm.net (John Fortin) Date: Sun, 11 Jul 1999 16:25:00 -0000 Subject: dlopen error References: <199907112153.QAA29977@mercury.xraylith.wisc.edu> Message-ID: <3789294D.5F9165AA@ibm.net> Mumit, It seems that NT SP5 had DirectX V3 support in it. Maybe that where ddraw.dll came from.. Also Win2K (NT 5.0) is supposed to support DirectX 7.0 As for Glide, I am guessing that it uses DirectX 2.0 since it can run on NT John Mumit Khan wrote: > > "Suhaib M. Siddiqi" writes: > > > > I noticed, glide-0-0-0.dll on your system is pulling DDRAW.DLL too? > > I do not have DDRAW.DLL. It is actually DirectDraw/DirectX DLL, as > > John pointed out. I do not have DirectX installed. On NT 4.0 newer > > versions of DirectDraw/DirectX are not supported. That is why I never > > installed DirectD/DirectX. When you patched 3Dfx headers and created > > the implib for Glide, could it be possible that it got linked to > > DDRAW too? I cannot see that though under objdump. All the DLLs from GGI > > get opened, except glide-0-0-0.dll. I also compiled today > > terminfo-0-0-0.dll of GGI. terminfo does display using simple stdin/stdout. > > It was a good decision, because that helped me find a new bug in libX11.dll, > > which I did not notice until now. > > The Glide SDK DLL itself depends on DDRAW.DLL, and nothing you or I do > will change that. Sorry. Do an objdump on the Glide SDK DLL and you'll > see. > > I don't know how I have DDRAW.DLL on this NT machine that I use for > testing our own software, and don't even remember installing DirectDraw. > Perhaps some other software installed it. > > Regards, > Mumit From ssiddiqi@inspirepharm.com Sun Jul 11 16:34:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 16:34:00 -0000 Subject: dlopen error References: <3789294D.5F9165AA@ibm.net> Message-ID: >> Mumit, > It seems that NT SP5 had DirectX V3 support in it. Maybe that where > ddraw.dll came from.. > > Also Win2K (NT 5.0) is supposed to support DirectX 7.0 > > As for Glide, I am guessing that it uses DirectX 2.0 since > it can run > on NT > John, You are absolutely right!!! :-) I just installed DiectX SDK on my NT and now glide-0-0-0.dll (the glide driver in GGI) opens without problems. Although I still cannot do display on my screen. This display problem is a bug in XGGI code which Marcus has to fix. It tries to do display in Marcus invented mansync routines and Windows NT knows nothing about mansync, it returns a Dr. Watson error. Here is out put from command line (debug mode). It supposed to call the mansync.dll from ggi after last line but I get a dr.watson error and everything hanged. We are getting there slowly. Suhaib bash-2.02$ LibGII: Debugging=255 LibGGI: Debugging=255 LibGGI: ggiOpen("glide") called LibGGI: Loading driver glide LibGGI: _ggiAddDL(0x10071118, "glide", "(null)", 0x1) called LibGGI: _ggiLoadDL("/usr/local/lib/ggi\display/glide-0-0-0.dll", 0x1) called LibGGI: hand.handle=0x1a480000 LibGGI: hand.init=0x1a483424 LibGGI: hand.cleanup=0x1a483868 LibGGI: _ggiLoadDL returned 0x10071538 LibGGI: GLIDE-lib starting LibGII: Allocating input structure LibGII: _giiEvQueueAllocate(0x1006ee20) called LibGII: Got queue_set: 0x1006f008 LibGII: giiOpen adding "x", "", 0x0 LibGII: _giiLoadDL("x","(NULL)") called LibGII: hand.handle=0x1aac0000 LibGII: hand.init=0x1aac1b1c LibGII: _giiLoadDL returned 0x1006f060 > John > > Mumit Khan wrote: > > > > "Suhaib M. Siddiqi" writes: > > > > > > I noticed, glide-0-0-0.dll on your system is pulling DDRAW.DLL too? > > > I do not have DDRAW.DLL. It is actually DirectDraw/DirectX DLL, as > > > John pointed out. I do not have DirectX installed. On NT 4.0 newer > > > versions of DirectDraw/DirectX are not supported. That is why I never > > > installed DirectD/DirectX. When you patched 3Dfx headers and created > > > the implib for Glide, could it be possible that it got linked to > > > DDRAW too? I cannot see that though under objdump. All the > DLLs from GGI > > > get opened, except glide-0-0-0.dll. I also compiled today > > > terminfo-0-0-0.dll of GGI. terminfo does display using > simple stdin/stdout. > > > It was a good decision, because that helped me find a new bug > in libX11.dll, > > > which I did not notice until now. > > > > The Glide SDK DLL itself depends on DDRAW.DLL, and nothing you or I do > > will change that. Sorry. Do an objdump on the Glide SDK DLL and you'll > > see. > > > > I don't know how I have DDRAW.DLL on this NT machine that I use for > > testing our own software, and don't even remember installing DirectDraw. > > Perhaps some other software installed it. > > > > Regards, > > Mumit > From gary@oranda.demon.co.uk Sun Jul 11 16:55:00 1999 From: gary@oranda.demon.co.uk (Gary V. Vaughan) Date: Sun, 11 Jul 1999 16:55:00 -0000 Subject: dlopen error References: <199907111921.OAA29216@mercury.xraylith.wisc.edu> Message-ID: <19990712002950.H648@demon.co.uk> On Sun, Jul 11, 1999 at 02:20:59PM -0500, Mumit Khan wrote: > "Suhaib M. Siddiqi" writes: > > > > Ok, now when I ran objdump I get the listing. > > > > DLL Name" > > DLL Name: libgg-0-0-6.dll > > DLL Name: libggi-2-0-0.dll > > DLL Name: libgii-0-0-6.dll > > DLL Name: cygwin1.dll > > DLL Name: Glide2x.dll > > DLL Name: kernel32.dll > > > > So what I did I copied all these DLLs into the same directory where > > glide-0-0-0.dll is. Now the error message changed from 127 to 12, i.e > > The specified module could not be found. > > I do not which other module it is searching. > > This a Windows NT, machine with Banshee/Voodoo card and its drivers > > installed. Therefore, hardware cannot be an issue. > > But each of these can be dependent on other DLLs that your machine may > not have. The one in particular is DDRAW.DLL, which I know nothing about > but needed by GLIDE2X.DLL. That's why I suggested using the debugger > which prints out the various DLLs as they're being loaded. You can run > `objdump -p | grep "DLL Name"' on the DLLs as well to see what they I am still maintaining the (rather slow) shell version of ldd for cygwin which extracts the entire dependency tree from any executable or dll and elminated duplicates (much like the real ldd on unix), it is available from my homepage (see .sig). Cheers, Gary. -- ___ _ ___ __ _ email:gary@oranda.demon.co.uk / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ gary@gnu.org | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ pgp-2 public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/pgp From ssiddiqi@inspirepharm.com Sun Jul 11 17:46:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 17:46:00 -0000 Subject: dlopen error References: <19990712002950.H648@demon.co.uk> Message-ID: Gary, Thanks. Your ldd gives a real picture. It will be great tool for development. Regards Suhaib bash-2.02$ ldd /usr/local/lib/ggi/display/glide-0-0-0.dll glide-0-0-0.dll -> /usr/local/lib/ggi/display/glide-0-0-0.dll libgg-0-0-6.dll -> /usr/local/lib/ggi/display/libgg-0-0-6.dll libggi-2-0-0.dll -> /usr/local/lib/ggi/display/libggi-2-0-0.dll libgii-0-0-6.dll -> /usr/local/lib/ggi/display/libgii-0-0-6.dll cygwin1.dll -> /e/pgi/cygusr/H-I586~1/bin/cygwin1.dll glide2x.dll -> /usr/local/lib/ggi/display/glide2x.dll kernel32.dll -> /WINNT/system32/kernel32.dll ntdll.dll -> /WINNT/system32/ntdll.dll ddraw.dll -> /usr/local/lib/ggi/display/ddraw.dll advapi32.dll -> /WINNT/system32/advapi32.dll user32.dll -> /WINNT/system32/user32.dll gdi32.dll -> /WINNT/system32/gdi32.dll rpcrt4.dll -> /WINNT/system32/rpcrt4.dll winmm.dll -> /WINNT/system32/winmm.dll > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Gary V. > Vaughan > Sent: Sunday, July 11, 1999 7:30 PM > To: Mumit Khan > Cc: Suhaib M. Siddiqi; Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: Re: dlopen error > > > On Sun, Jul 11, 1999 at 02:20:59PM -0500, Mumit Khan wrote: > > "Suhaib M. Siddiqi" writes: > > > > > > Ok, now when I ran objdump I get the listing. > > > > > > DLL Name" > > > DLL Name: libgg-0-0-6.dll > > > DLL Name: libggi-2-0-0.dll > > > DLL Name: libgii-0-0-6.dll > > > DLL Name: cygwin1.dll > > > DLL Name: Glide2x.dll > > > DLL Name: kernel32.dll > > > > > > So what I did I copied all these DLLs into the same directory where > > > glide-0-0-0.dll is. Now the error message changed from 127 to 12, i.e > > > The specified module could not be found. > > > I do not which other module it is searching. > > > This a Windows NT, machine with Banshee/Voodoo card and its drivers > > > installed. Therefore, hardware cannot be an issue. > > > > But each of these can be dependent on other DLLs that your machine may > > not have. The one in particular is DDRAW.DLL, which I know nothing about > > but needed by GLIDE2X.DLL. That's why I suggested using the debugger > > which prints out the various DLLs as they're being loaded. You can run > > `objdump -p | grep "DLL Name"' on the DLLs as well to see what they > > I am still maintaining the (rather slow) shell version of ldd for > cygwin which extracts the entire dependency tree from any executable > or dll and elminated duplicates (much like the real ldd on unix), it > is available from my homepage (see .sig). > > Cheers, > Gary. > -- > ___ _ ___ __ _ > email:gary@oranda.demon.co.uk > / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ > gary@gnu.org > | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ > \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ > home page: /___/ /___/ pgp-2 > public key: > http://www.oranda.demon.co.uk > http://www.oranda.demon.co.uk/pgp > From ssiddiqi@inspirepharm.com Sun Jul 11 17:53:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 11 Jul 1999 17:53:00 -0000 Subject: Xggi/glide References: Message-ID: Ummm, with any optimization it did work. i tool all the flags -ansi, -pedantic and blah blah out, and it compiled. By the way, the tele module in /degas/lib/libggi/display/tele was doing the same thing, always. I could never figure out what was going on, so I started disableing (i.e --disable-tele) module compilation. I had this problem with anothe X11/MOTIF application which I was trying to port from SGI. and I kept getting this b0 crashes of assembler. This weekend when i took some of the uneccessary socket stuff out from X11lib then X11 compilation also gave this error. That is when i though i should check with gcc Pro to see what this crash of assembler with b0 error means, which have seen a few times. Suhaib > -----Original Message----- > From: Mumit Khan [ mailto:khan@xraylith.wisc.edu ] > Sent: Sunday, July 11, 1999 8:18 PM > To: Suhaib M. Siddiqi > Subject: RE: Xggi/glide > > > On Sun, 11 Jul 1999, Suhaib M. Siddiqi wrote: > > > > > Mumit, > > It is still doing assembler crash. > > I am using > > bash-2.02$ > > gcc -c -save-temps -c -O2 -ansi -pedantic -I../.. -I../../exports/in > > clude -D__i386__ -DX_LOCALE -D_MT -DNO_TCP_H -DFUNCPROTO=15 > -DNARROWPROTO -D > > _XL > > IBINT_ -I../../lib/xtrans -DTCPCONN -DHAS_STICKY_DIR_BIT > -DX11_t -DTRANS_CL > > IEN > > T x11trans.c > > ../../lib/xtrans/Xtrans.c: In function `_X11TransSelectTransport': > > In file included from x11trans.c:91: > > ../../lib/xtrans/Xtrans.c:185: warning: ANSI C forbids > braced-groups within > > expr > > essions > > x11trans.s: Assembler messages: > > x11trans.s:814: Error: bad register name `b0' > > bash-2.02$ > > > > Got it. You've found a genuine bug in all versions of gcc, including the > upcoming gcc-2.95. I'll see if I can find a cure sometime soon. > > In the meantime, your only hope is to compile that one file without > optimization (ie., no -O option). > > Regards, > Mumit > > From khan@xraylith.wisc.EDU Sun Jul 11 18:03:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sun, 11 Jul 1999 18:03:00 -0000 Subject: Xggi/glide References: Message-ID: <199907120103.UAA30519@mercury.xraylith.wisc.edu> "Suhaib M. Siddiqi" writes: > > Ummm, with any optimization it did work. i tool all the flags -ansi, > -pedantic and blah blah out, and it compiled. I just sent you a note on this -- the problem is with your headers, not with GCC and not with Cygwin. Looking at the preprocessed output you had sent me, it looks as if you're using the headers distributed with PGI, and asm/byteorder.h is incorrect (from an older newlib release it would seem). > By the way, the tele module in /degas/lib/libggi/display/tele was doing the > same > thing, always. I could never figure out what was going on, so I started > disableing (i.e --disable-tele) module compilation. I had this problem > with anothe X11/MOTIF application which I was trying to port from SGI. and I > kept getting > this b0 crashes of assembler. This weekend when i took some of the > uneccessary socket > stuff out from X11lib then X11 compilation also gave this error. That is > when i though > i should check with gcc Pro to see what this crash of assembler with b0 > error means, which > have seen a few times. Dump the PGI headers and install the Cygwin b20.1 headers on top. It's very hard to help debug if you use a different set of headers than the rest of us. If you're not using PGI (which I guessed because the preprocessed files have pgi in the directory names), then you need to somehow sync your headers with Cygwin. Regards, Mumit From Ssiddiqi@InspirePharm.Com Wed Jul 14 17:02:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Wed, 14 Jul 1999 17:02:00 -0000 Subject: Xggi/glide References: Message-ID: > > from cfbpntwin.c:64: > > > c:/cygnus/CYGWIN~4/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/egcs- > 2.91.66/.. > > /../ > > ../../i586-cygwin32/include/stdlib.h:46: parse error before `int' > > make[5]: *** [cfbpntwin.o] Error 1 > > > > Line 46 declares a function named abs, and it might be that there is an > existing abs macro when the compiler sees it and croaks. It really is > useful to look at the preprocessed file and see what happens there after > pre-processing. > > Regards, > Mumit > > Mumit, Thanks. Actually problem exsists in the recent snapshots too. i tried a recent snap shot and in that case the number of line moved from 46 to 51. If I compile with -O2 flag it works, but with -g flag it gives a parse error. The code compiled with optimization after doing changes over the weekend, is doing core dumps. I need to get everything compiled with -g so I can debug it. I forwarding this message to list, perhaps someone else on Xfree project also may have notice this problem. Attached is the --save-temps file and code. Thansk for your help. Suhaib From Ssiddiqi@InspirePharm.Com Wed Jul 14 17:03:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Wed, 14 Jul 1999 17:03:00 -0000 Subject: Patch from Takayuki Message-ID: Hi Takayuki, You following patch did not do any good, instead I started getting * not found (where exectbale_name is the name of executable for example mkfontdir.exe), when doing make install and making fonts. Therefore, I removed your patch. Sorry about it. Regards Suhaib ---------------------------------------- Hi, Suhaib. First of all, thanks to your great job! I found and fixed three problems in your XFree86 port, including 'gcc -E -' hang. (I use xfree86-3331.tar.gz single tarball and cf.tar.gz as of May 27.) Though I finally encountered 'Full build of Release 6.3(4?) of the X Window System complete.' message, I'm still with many errors. Anyway, here is the description, followed by the patch attached. (1) 'gcc -E -' problem In cygwin.cf, we have, #define CcCmd gcc #define CppCmd CcCmd -E - However, 'gcc -E' isn't fully compatible with direct invocation of cpp. Value of CPP: /lib/cpp 'gcc -E' 'gcc -E -' $(CPP) < file: OK NG OK $(CPP) file: OK OK NG Unfortunately, the latter style was used in CPPOnlyAsm macro, which is defined in xf86.rules. So, we need to override this in cygwin.rules. (2) xc/exports/bin/*.exe must run without preinstalled X When building in program/xkbcomp/SUBDIR, xkbcomp in xc/exports/bin is run. However, if you don't have preexisting X environment, it fails with 'missing libX11.dll'. We need *.dll in xc/exports/bin for cleaner compilation. In addition, we have to avoid symlinking .exe and .dll under xc/exports/bin, because Win32 can't handle symlinks. I added LinkBuildDLL and LinkBuildBinary in cygwin.rules. (3) StdIncDir and PostIncDir settings In cygwin.cf, you have, #define StdIncDir `CcCmd --print-libgcc-file-name | sed ':libgcc.a:../../../../i586-cygwin32/include:/cygnus/cygwin-b20/local/includ e:/cygnus/cygwin-b20/include:/cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin3 2/include:'|sed 's,\\\\,/,g'` #define PostIncDir `CcCmd --print-libgcc-file-name | sed ':libgcc.a:/include:'|sed 's,\\\\,/,g'` But I can't understand the above sed command. Doesn't this suffice? #define StdIncDir `CcCmd --print-libgcc-file-name | sed 's,\\\\,/,g' | sed 's,libgcc.a,../../../../i586-cygwin32/include,'` #define PostIncDir `CcCmd --print-libgcc-file-name | sed 's,\\\\,/,g' | sed 's,libgcc.a,include,'` I hope it helps. Regards, --------------- Takayuki TAMURA (ttathome@remus.dti.ne.jp) --- ./cygwin.cf.orig Wed May 26 05:20:09 1999 +++ ./cygwin.cf Thu Jun 03 20:21:15 1999 @@ -77,8 +77,8 @@ #define LexCmd flex -l #define LexLib -lfl #define PreProcessCmd CcCmd -E -#define StdIncDir `CcCmd --print-libgcc-file-name | sed ':libgcc.a:../../../../i586-cygwin32/include:/cygnus/cygwin-b20/local/includ e:/cygnus/cygwin-b20/include:/cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin3 2/include:'|sed 's,\\\\,/,g'` -#define PostIncDir `CcCmd --print-libgcc-file-name | sed ':libgcc.a:/include:'|sed 's,\\\\,/,g'` +#define StdIncDir `CcCmd --print-libgcc-file-name | sed 's,\\\\,/,g' | sed 's,libgcc.a,../../../../i586-cygwin32/include,'` +#define PostIncDir `CcCmd --print-libgcc-file-name | sed 's,\\\\,/,g' | sed 's,libgcc.a,include,'` #define LdCombineFlags -r #define OptimizedCDebugFlags -O2 -s -mpentium #define StandardDefines -D__i386__ -DX_LOCALE -D_MT -DNO_TCP_H -D__CYGWIN32_ _ -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE --- ./cygwin.rules.orig Thu May 13 20:45:56 1999 +++ ./cygwin.rules Thu Jun 03 21:29:56 1999 @@ -1,6 +1,34 @@ XCOMM $XConsortium: cygwin.rules /main/12 1996/01/03 14:51:18 kaleb $ /* + * Override CPPOnlyAsm - our CppCmd can't take filename as arguments. + */ +#define CPPOnlyAsm(basename,options) RemoveFile(basename.i) @@\ + $(CPP) AsmDefines $(DEFINES) $(INCLUDES) options basename.i + +/* + * LinkBuildBinary - export a binary to exports/bin. + */ +#define LinkBuildBinary(binary) @@\ +all:: $(BUILDBINDIR)/ProgramTargetName(binary) ProgramTargetName(binary) @@\ + @@\ +$(BUILDBINDIR)/ProgramTargetName(binary): ProgramTargetName(binary) @@\ + RemoveFile($@) @@\ + cd $(BUILDBINDIR) && $(CP) $(BUILDBINTOP)/$(CURRENT_DIR)/ProgramTargetName(binary) . + +/* + * LinkBuildDLL - export a .dll to exports/bin. + */ +#ifdef UseInstalled +#define LinkBuildDLL(lib) $(_NULLCMD_) +#else +#define LinkBuildDLL(lib) MakeDir($(BUILDBINDIR)) @@\ + RemoveFile($(BUILDBINDIR)/lib) @@\ + cd $(BUILDBINDIR) && $(CP) $(BUILDBINTOP)/$(CURRENT_DIR)/lib . +#endif + +/* * Cygwin shared library rules (DLL versions) */ #define HasSharedLibraries YES @@ -76,6 +104,7 @@ RemoveFile(Concat3(lib,libname,.dll)) @@\ MakeDLL(libname,solist) @@\ LinkBuildLibrary(Concat3(lib,libname,.a)) @@\ + LinkBuildDLL(Concat3(lib,libname,.dll)) @@\ clean:: @@\ RemoveFile(LibraryTargetName(libname)) @@\ RemoveFile(Concat3(lib,libname,.dll)) @@\ From Ssiddiqi@InspirePharm.Com Wed Jul 14 17:04:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Wed, 14 Jul 1999 17:04:00 -0000 Subject: Xggi/glide References: Message-ID: Mumit, thanks. It was misc.h in Xserver/include. It had #if!defined(LYNX) && !defined(AMOEBA) #ifndef (abs) #define abs(x) ((x) > 0 ? (x) : -(x)) I added && !defined(__CYGWIN32__) to it. Should I upgrade to gcc 2.95? gcc from egcs-1.1.2, with July 03 snapshot, is skipping files and complaining file not found or giving compiler errors, as I wrote in previous mail. Regards Suhaib > -----Original Message----- > From: Mumit Khan [ mailto:khan@xraylith.wisc.EDU ] > Sent: Wednesday, July 14, 1999 3:36 PM > To: Suhaib M. Siddiqi > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: RE: Xggi/glide > > > On Wed, 14 Jul 1999, Suhaib M. Siddiqi wrote: > > > > > > > from cfbpntwin.c:64: > > > > > > > c:/cygnus/CYGWIN~4/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/egcs- > > > 2.91.66/.. > > > > /../ > > > > ../../i586-cygwin32/include/stdlib.h:46: parse error before `int' > > > > make[5]: *** [cfbpntwin.o] Error 1 > > > > > > > > > > Line 46 declares a function named abs, and it might be that > there is an > > > existing abs macro when the compiler sees it and croaks. It really is > > > useful to look at the preprocessed file and see what happens > there after > > > pre-processing. > > > > > > Regards, > > > Mumit > > > > > > > > > > Mumit, > > > > Thanks. Actually problem exsists in the recent snapshots too. > i tried a > > recent > > snap shot and in that case the number of line moved from 46 to 51. If I > > compile with -O2 flag > > it works, but with -g flag it gives a parse error. The code > compiled with > > optimization > > after doing changes over the weekend, is doing core dumps. I > need to get > > everything compiled > > with -g so I can debug it. I forwarding this message to list, perhaps > > someone else > > on Xfree project also may have notice this problem. > > > > Attached is the --save-temps file and code. > > > > Suhaib, > > Please follow my suggestion and take a look at the preprocessed file. The > problem is obvious. Some header file is defining a macro named > abs(x), and > it's being turned on or off depending on if -g or -Ox is used. See line > 15671 in the preprocessed file for details. > > What is happening is the following: > > - some header, say a.h, file is doing something like the following: > > #define abs(x) ((x) > 0 ? (x) : -(x)) > > - stdlib.h is declaring a library function, abs, as the following: > > int abs (int); > > Now imagine the following sequence of includes: > > #include "a.h" > #include > > and now you see what will happen when the compiler sees the abs() > prototype > in stdlib.h after encountering the macro in a.h. > > Tracking it down should be pretty easy. Compile the file with -H, and > see what includes are coming in *before* stdlib.h. Grep for abs in those > files and you'll find the culprit. Another way to find it is to do the > following: add the following somewhere in your .c file: > > #define abs(x) (x) > > and cpp will complain about duplicate abs macro and show you where the > previous definition was encountered. > > Regards, > Mumit > > From Ssiddiqi@InspirePharm.Com Wed Jul 14 17:04:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Wed, 14 Jul 1999 17:04:00 -0000 Subject: GCC 1.1.2 strang behavior Message-ID: Mumit, egcs 1.1.2 with Cygwin snapshot of July 3, 1999 is doinf bizzare hings. It will report once in a while a compiler error. But when i cd to that directory and type the gcc command manually it compiles, the same file. Sometime it also reports missing files (file not found) but cd'ing to that directory and typing the gcc and flags mannually will create the object file. The -save-temps files are attached. Suhaib gcc -c -g -I../include -I../../../exports/include/X11 -I../../../include/f onts -I../../../include/extensions -I../../.. -I../../../exports/include -D__i 386_ _ -DX_LOCALE -D_MT -DNO_TCP_H -DSHAPE -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -D PIXPRIV -DGCCUSESGAS -DSTATIC_COLOR -DAVOID_GLYPHBLT -DPIXPRIV -DXFreeXDGA -DN DEBUG -DFUNCPROTO=15 -DNARROWPROTO initatoms.c ../../gcc/gcc.c:2574: Internal compiler error in function execute From khan@xraylith.wisc.EDU Wed Jul 14 17:04:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Wed, 14 Jul 1999 17:04:00 -0000 Subject: Xggi/glide References: Message-ID: On Wed, 14 Jul 1999, Suhaib M. Siddiqi wrote: > thanks. It was misc.h in Xserver/include. It had > #if!defined(LYNX) && !defined(AMOEBA) > #ifndef (abs) > #define abs(x) ((x) > 0 ? (x) : -(x)) > > > I added && !defined(__CYGWIN32__) to it. Too bad you have to deal with sloppy code. This can be done the right way without these adhoc defines. Also, please use __CYGWIN__, not __CYGWIN32__. > Should I upgrade to gcc 2.95? gcc from egcs-1.1.2, with July 03 snapshot, > is skipping files and > complaining file not found or giving compiler errors, as I wrote in previous > mail. The problem is in Cygwin, and I believe on Win9x, where multiple files end up getting the same inode numbers. The C preprocessor in egcs and gcc use the inode numbers to avoid including the same file multiple times, and this causes problems when two *different* files have the same inode number. I'm going to disable this inode optimization for the next snapshot and quit possibly for the release as well. This has caused a tremendous amount of confusion and eaten up lots of my time trying to find a problem that only shows up on others people's machines! If you see this problem on NT as well, please let me know. In the meantime, here's to see if you have the same problem: - compile file foo.c file with -H option. You'll see all the includes. - now check the inode numbers of these includes. I'm including a simple program at the end. $ gcc -o inode-test.exe inode-test.c $ ./inode-test file1 [file2 ... ] Regards, Mumit == cut here to end /* inode-test.c: Find the inode given a file. */ #include #include #include #include int main (int argc, char *argv[]) { int i; for (i = 1; i < argc; i++) { struct stat buf1, buf2; int result; const char *path = argv[i]; printf ("File: %s\n", path); result = stat (path, &buf1); if (result == 0) { printf ("STAT() reports:\n ================\n"); printf (" st_mode = %d\n", buf1.st_mode); printf (" st_ino = %ld\n", buf1.st_ino); printf (" st_dev = %d\n", buf1.st_dev); printf (" st_nlink = %d\n", buf1.st_nlink); printf (" st_uid = %d\n", buf1.st_uid); printf (" st_gid = %d\n", buf1.st_gid); printf (" st_size = %ld\n", buf1.st_size); printf (" st_rdev = %d\n", buf1.st_rdev); printf (" st_blksize = %ld\n", buf1.st_blksize); printf (" st_blocks = %ld\n", buf1.st_blocks); } else { perror (path); } result = lstat (path, &buf2); if (result == 0) { printf ("LSTAT() reports:\n ================\n"); printf (" st_mode = %d\n", buf2.st_mode); printf (" st_ino = %ld\n", buf2.st_ino); printf (" st_dev = %d\n", buf2.st_dev); printf (" st_nlink = %d\n", buf2.st_nlink); printf (" st_uid = %d\n", buf2.st_uid); printf (" st_gid = %d\n", buf2.st_gid); printf (" st_size = %ld\n", buf2.st_size); printf (" st_rdev = %d\n", buf2.st_rdev); printf (" st_blksize = %ld\n", buf2.st_blksize); printf (" st_blocks = %ld\n", buf2.st_blocks); } else { perror (path); } } return 0; } From khan@xraylith.wisc.EDU Wed Jul 14 17:04:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Wed, 14 Jul 1999 17:04:00 -0000 Subject: Xggi/glide References: Message-ID: On Wed, 14 Jul 1999, Suhaib M. Siddiqi wrote: > > > > from cfbpntwin.c:64: > > > > > c:/cygnus/CYGWIN~4/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/egcs- > > 2.91.66/.. > > > /../ > > > ../../i586-cygwin32/include/stdlib.h:46: parse error before `int' > > > make[5]: *** [cfbpntwin.o] Error 1 > > > > > > > Line 46 declares a function named abs, and it might be that there is an > > existing abs macro when the compiler sees it and croaks. It really is > > useful to look at the preprocessed file and see what happens there after > > pre-processing. > > > > Regards, > > Mumit > > > > > > Mumit, > > Thanks. Actually problem exsists in the recent snapshots too. i tried a > recent > snap shot and in that case the number of line moved from 46 to 51. If I > compile with -O2 flag > it works, but with -g flag it gives a parse error. The code compiled with > optimization > after doing changes over the weekend, is doing core dumps. I need to get > everything compiled > with -g so I can debug it. I forwarding this message to list, perhaps > someone else > on Xfree project also may have notice this problem. > > Attached is the --save-temps file and code. > Suhaib, Please follow my suggestion and take a look at the preprocessed file. The problem is obvious. Some header file is defining a macro named abs(x), and it's being turned on or off depending on if -g or -Ox is used. See line 15671 in the preprocessed file for details. What is happening is the following: - some header, say a.h, file is doing something like the following: #define abs(x) ((x) > 0 ? (x) : -(x)) - stdlib.h is declaring a library function, abs, as the following: int abs (int); Now imagine the following sequence of includes: #include "a.h" #include and now you see what will happen when the compiler sees the abs() prototype in stdlib.h after encountering the macro in a.h. Tracking it down should be pretty easy. Compile the file with -H, and see what includes are coming in *before* stdlib.h. Grep for abs in those files and you'll find the culprit. Another way to find it is to do the following: add the following somewhere in your .c file: #define abs(x) (x) and cpp will complain about duplicate abs macro and show you where the previous definition was encountered. Regards, Mumit From ssiddiqi@inspirepharm.com Wed Jul 14 17:05:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Wed, 14 Jul 1999 17:05:00 -0000 Subject: Xggi/glide References: Message-ID: Mumit, It was from NT 4.0 SP 5. I do not use Win95/98. I had enough troubles with Win95/98. Last year all the departments under my control were forced to give up Windows 95/98 and use NT 4.0. Regards Suhaib > -----Original Message----- > From: Mumit Khan [ mailto:khan@xraylith.wisc.EDU ] > Sent: Wednesday, July 14, 1999 4:11 PM > To: Suhaib M. Siddiqi > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: RE: Xggi/glide > > > On Wed, 14 Jul 1999, Suhaib M. Siddiqi wrote: > > > thanks. It was misc.h in Xserver/include. It had > > #if!defined(LYNX) && !defined(AMOEBA) > > #ifndef (abs) > > #define abs(x) ((x) > 0 ? (x) : -(x)) > > > > > > I added && !defined(__CYGWIN32__) to it. > > Too bad you have to deal with sloppy code. This can be done the right > way without these adhoc defines. Also, please use __CYGWIN__, not > __CYGWIN32__. > > > Should I upgrade to gcc 2.95? gcc from egcs-1.1.2, with July > 03 snapshot, > > is skipping files and > > complaining file not found or giving compiler errors, as I > wrote in previous > > mail. > > The problem is in Cygwin, and I believe on Win9x, where multiple files end > up getting the same inode numbers. The C preprocessor in egcs and gcc use > the inode numbers to avoid including the same file multiple > times, and this > causes problems when two *different* files have the same inode number. > > I'm going to disable this inode optimization for the next snapshot and > quit possibly for the release as well. This has caused a tremendous > amount of confusion and eaten up lots of my time trying to find a problem > that only shows up on others people's machines! > > If you see this problem on NT as well, please let me know. In the > meantime, > here's to see if you have the same problem: > > - compile file foo.c file with -H option. You'll see all the includes. > - now check the inode numbers of these includes. I'm including a simple > program at the end. > > $ gcc -o inode-test.exe inode-test.c > $ ./inode-test file1 [file2 ... ] > > Regards, > Mumit > > == cut here to end > /* inode-test.c: Find the inode given a file. */ > > #include > #include > #include > #include > > int > main (int argc, char *argv[]) > { > int i; > for (i = 1; i < argc; i++) > { > struct stat buf1, buf2; > int result; > const char *path = argv[i]; > printf ("File: %s\n", path); > > result = stat (path, &buf1); > > if (result == 0) > { > printf ("STAT() reports:\n ================\n"); > printf (" st_mode = %d\n", buf1.st_mode); > printf (" st_ino = %ld\n", buf1.st_ino); > printf (" st_dev = %d\n", buf1.st_dev); > printf (" st_nlink = %d\n", buf1.st_nlink); > printf (" st_uid = %d\n", buf1.st_uid); > printf (" st_gid = %d\n", buf1.st_gid); > printf (" st_size = %ld\n", buf1.st_size); > printf (" st_rdev = %d\n", buf1.st_rdev); > printf (" st_blksize = %ld\n", buf1.st_blksize); > printf (" st_blocks = %ld\n", buf1.st_blocks); > } > else > { > perror (path); > } > > result = lstat (path, &buf2); > > if (result == 0) > { > printf ("LSTAT() reports:\n ================\n"); > printf (" st_mode = %d\n", buf2.st_mode); > printf (" st_ino = %ld\n", buf2.st_ino); > printf (" st_dev = %d\n", buf2.st_dev); > printf (" st_nlink = %d\n", buf2.st_nlink); > printf (" st_uid = %d\n", buf2.st_uid); > printf (" st_gid = %d\n", buf2.st_gid); > printf (" st_size = %ld\n", buf2.st_size); > printf (" st_rdev = %d\n", buf2.st_rdev); > printf (" st_blksize = %ld\n", buf2.st_blksize); > printf (" st_blocks = %ld\n", buf2.st_blocks); > } > else > { > perror (path); > } > } > return 0; > } > From cgf@cygnus.com Wed Jul 14 20:27:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 14 Jul 1999 20:27:00 -0000 Subject: Xggi/glide References: Message-ID: <19990714232806.A5150@cygnus.com> On Wed, Jul 14, 1999 at 03:11:18PM -0500, Mumit Khan wrote: >On Wed, 14 Jul 1999, Suhaib M. Siddiqi wrote: >The problem is in Cygwin, and I believe on Win9x, where multiple files end >up getting the same inode numbers. The C preprocessor in egcs and gcc use >the inode numbers to avoid including the same file multiple times, and this >causes problems when two *different* files have the same inode number. Isn't this fixed in recent cygwin snapshots? There's still a chance that multiple files will get the same inode but it should not be as great as it once was. cgf From khan@xraylith.wisc.EDU Wed Jul 14 20:43:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Wed, 14 Jul 1999 20:43:00 -0000 Subject: Xggi/glide References: <19990714232806.A5150@cygnus.com> Message-ID: On Wed, 14 Jul 1999, Chris Faylor wrote: > Isn't this fixed in recent cygwin snapshots? There's still a chance that > multiple files will get the same inode but it should not be as great as > it once was. I've heard positive reports on newer snapshots. But, since you say that there is a chance it might still happen, I'm going to disable the inode based optimization in cpp to avoid future problems. This unfortunately causes subtle and confusing compile time errors/glitches that are very hard to track down, even for experienced users. Suhaib is using NT 4.0, and I don't know if it can cause problems there as well. Regards, Mumit From Ssiddiqi@InspirePharm.Com Thu Jul 15 03:49:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Thu, 15 Jul 1999 03:49:00 -0000 Subject: Xggi/glide References: <19990714232806.A5150@cygnus.com> Message-ID: > > On Wed, Jul 14, 1999 at 03:11:18PM -0500, Mumit Khan wrote: > >On Wed, 14 Jul 1999, Suhaib M. Siddiqi wrote: > >The problem is in Cygwin, and I believe on Win9x, where multiple > files end > >up getting the same inode numbers. The C preprocessor in egcs and gcc use > >the inode numbers to avoid including the same file multiple > times, and this > >causes problems when two *different* files have the same inode number. > > Isn't this fixed in recent cygwin snapshots? There's still a chance that > multiple files will get the same inode but it should not be as great as > it once was. > > cgf > Chris, It was July 03 snapshot. I think previous snapshot was having inode problems on Wiun9x. With July 3 snapshot I had inode problem on NT 4.0 SP5. Suhaib From Ssiddiqi@InspirePharm.Com Thu Jul 15 07:28:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Thu, 15 Jul 1999 07:28:00 -0000 Subject: gcc-2.95 and Cygwin winsup References: Message-ID: Mumit, I am trying to compile July 05 snapshot of winsup-src (Cygwin) with gcc-2.95 19990626 snapshot from you. It does the following error. Is it also the inode problem? I am using cygwin-1990703-inst (snapshot) to compile July 05 snapshot. Also I am getting the path_conv warnning for almost each line of code. net.cc: At top level: net.cc:1741: Internal compiler error. net.cc:1741: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'. net.cc:1741: See for details. bash-2.02$ gcc -save-temps -c -fno-rtti -fno-exceptions -g -O2 -Wall -Wwrite-s> In file included from winsup.h:40, from net.cc:20: path.h: In method `int path_conv::set_has_acls(int = 1)': path.h:53: warning: control reaches end of non-void function `path_conv::set_has _acls(int)' net.cc: At top level: net.cc:1741: Internal compiler error. net.cc:1741: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'. net.cc:1741: See for details. bash-2.02$ Thanks for your help Suhaib From Ssiddiqi@InspirePharm.Com Thu Jul 15 07:32:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Thu, 15 Jul 1999 07:32:00 -0000 Subject: gcc-2.95 and Cygwin winsup References: Message-ID: By the way, with egcs-1.1.2 it compiled. Therefore I assume it could be a gcc-2.95 bug issue??? Suhaib > -----Original Message----- > From: Suhaib M. Siddiqi [ mailto:Ssiddiqi@InspirePharm.Com ] > Sent: Thursday, July 15, 1999 10:23 AM > To: Mumit Khan > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com; egcs-bugs@egcs.cygnus.com > Subject: RE: gcc-2.95 and Cygwin winsup > > > > > Mumit, > I am trying to compile July 05 snapshot of winsup-src (Cygwin) > with gcc-2.95 19990626 snapshot from you. > > It does the following error. Is it also the inode problem? > I am using cygwin-1990703-inst (snapshot) to compile July 05 snapshot. > > > Also I am getting the path_conv warnning for almost each line of code. > > net.cc: At top level: > net.cc:1741: Internal compiler error. > net.cc:1741: Please submit a full bug report to > `egcs-bugs@egcs.cygnus.com'. > net.cc:1741: See > for details. > bash-2.02$ gcc -save-temps -c -fno-rtti -fno-exceptions -g -O2 > -Wall -Wwrite-s> > In file included from winsup.h:40, > from net.cc:20: > path.h: In method `int path_conv::set_has_acls(int = 1)': > path.h:53: warning: control reaches end of non-void function > `path_conv::set_has > _acls(int)' > net.cc: At top level: > net.cc:1741: Internal compiler error. > net.cc:1741: Please submit a full bug report to > `egcs-bugs@egcs.cygnus.com'. > net.cc:1741: See > for details. > bash-2.02$ > > Thanks for your help > Suhaib > From cgf@cygnus.com Thu Jul 15 13:55:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Thu, 15 Jul 1999 13:55:00 -0000 Subject: Xggi/glide References: <19990714232806.A5150@cygnus.com> Message-ID: <19990715165621.A20193@cygnus.com> On Wed, Jul 14, 1999 at 09:34:59PM -0500, Mumit Khan wrote: >On Wed, 14 Jul 1999, Chris Faylor wrote: >> Isn't this fixed in recent cygwin snapshots? There's still a chance that >> multiple files will get the same inode but it should not be as great as >> it once was. > >I've heard positive reports on newer snapshots. But, since you say that >there is a chance it might still happen, I'm going to disable the inode >based optimization in cpp to avoid future problems. This unfortunately >causes subtle and confusing compile time errors/glitches that are very >hard to track down, even for experienced users. I agree that this feature should be turned off for Windows. In actuality, it's possible (but even more unlikely) that NT 4.0 will have duplicate inodes, too. I just didn't think that people would be seeing many (any?) of these problems with recent snapshots. cgf From Ssiddiqi@InspirePharm.Com Thu Jul 15 13:59:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Thu, 15 Jul 1999 13:59:00 -0000 Subject: Xggi/glide References: <19990715165621.A20193@cygnus.com> Message-ID: > > On Wed, Jul 14, 1999 at 09:34:59PM -0500, Mumit Khan wrote: > >On Wed, 14 Jul 1999, Chris Faylor wrote: > >> Isn't this fixed in recent cygwin snapshots? There's still a > chance that > >> multiple files will get the same inode but it should not be as great as > >> it once was. > > > >I've heard positive reports on newer snapshots. But, since you say that > >there is a chance it might still happen, I'm going to disable the inode > >based optimization in cpp to avoid future problems. This unfortunately > >causes subtle and confusing compile time errors/glitches that are very > >hard to track down, even for experienced users. > > I agree that this feature should be turned off for Windows. In > actuality, it's possible (but even more unlikely) that NT 4.0 will have > duplicate inodes, too. > > I just didn't think that people would be seeing many (any?) of these > problems with recent snapshots. > > cgf > I compiled the winsup from july 05 snapshot. The inode problem is fixed. I am using gcc-2.95. Actually Xfree code with gcc-2.95 and July 05 snapshot compiles much cleaner. Most of the warning messages disappered. Suhaib PS: The previous messages with attachments were untintional. i intded to sent them to Mumit, but hit the reply to all. Sorry about it. From Ssiddiqi@InspirePharm.Com Thu Jul 15 19:16:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Thu, 15 Jul 1999 19:16:00 -0000 Subject: Xggi References: <375088D9.57CDE6C9@stacken.kth.se> Message-ID: Hi Marucs, To test how XGGI X-server works on Linux. I compiled it on RedHat 6.0 (glibc 2.1.1). I have same problems on Windows. Below is the screen capture of the DEBUG from Linux. LibGII: Debugging=255 LibGGI: Debugging=255 LibGGI: ggiOpen("display-x::0.0") called LibGGI: Loading driver display-x::0.0 LibGGI: _ggiAddDL(0x81d0d10, "display-x", ":0.0", 0x1) called LibGGI: _ggiLoadDL("/usr/local/lib/ggi/display/X.so", 0x1) called LibGGI: hand.handle=0x81d1060 LibGGI: hand.init=0x4013fab4 LibGGI: hand.cleanup=0x40140004 LibGGI: _ggiLoadDL returned 0x81d1910 LibGGI: X-target wants display :0.0 After the line LibGGI: X-target wants display :0.0 it hangs. No display. I used the command XGGI -targets X & It seems to me it is having problems to connect to X11 libraries. The same symptoms are on Windows. All the X11 libraries from XFree86 which exists on Linux, are available on Windows/Cygwin. I suspect it could be a configuration issue? Regards Suhaib From Ssiddiqi@InspirePharm.Com Fri Jul 16 09:42:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Fri, 16 Jul 1999 09:42:00 -0000 Subject: Patch from Takayuki References: Message-ID: > > First of all, thanks to your great job! > > > > I found and fixed three problems in your XFree86 port, including > > 'gcc -E -' hang. > > (I use xfree86-3331.tar.gz single tarball and cf.tar.gz as of May 27.) > > > > Is the gcc -E problem solved now? > > Mumit > > Mumit, Yes, the gcc -E works. the *.s files are needed anyway. they are for S3 hardware linux specific. There are other problems. libXt, libXau and libXMu when build as DLLs causes libXt.dll to do coredump, particularly xterm. I tried ssveral combinations 1) libXT.dll and Xaw and Xmu as static (still coredumps) 2) libXt.a (static and others as Dll (still core dump) GDB traced the coredump to 3 files, one in libXt directory and 3 in xterm source code directory. Code looks OK to me. When if any of the above libs are made as DLLs, when XtWidgetCreate is activated, it causes coredump. Strangely, if all 3 are static then everything goes fine. Suhaib From khan@xraylith.wisc.EDU Fri Jul 16 13:24:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Fri, 16 Jul 1999 13:24:00 -0000 Subject: Patch from Takayuki References: Message-ID: <199907161916.OAA12209@mercury.xraylith.wisc.edu> "Suhaib M. Siddiqi" writes: > > There are other problems. libXt, libXau and libXMu when build as DLLs > causes libXt.dll to do coredump, particularly xterm. > I tried ssveral combinations > 1) libXT.dll and Xaw and Xmu as static (still coredumps) > 2) libXt.a (static and others as Dll (still core dump) > > GDB traced the coredump to 3 files, one in libXt directory > and 3 in xterm source code directory. Code looks OK to me. > When if any of the above libs are made as DLLs, when XtWidgetCreate > is activated, it causes coredump. Strangely, if all 3 are static then > everything goes fine. > This sounds like the initialization problem of variables from the DLL. Have you looked at the changes that the other ports (eg., Sergey's) to see what they've done? I remember a message from Sergey long ago related to this issue; however, I don't remember the details anymore. I don't know the issues involved here, but it would seem that the best approach is to first fix ggi to work with the existing X11 ports to cygwin and then just use those instead of trying to do yet another x11r6. port for Cygwin. Regards, Mumit From ssiddiqi@inspire.InspirePharm.Com Fri Jul 16 13:29:00 1999 From: ssiddiqi@inspire.InspirePharm.Com (Suhaib M. Siddiqi) Date: Fri, 16 Jul 1999 13:29:00 -0000 Subject: Patch from Takayuki Message-ID: <199907162032.QAA22284@inspire.InspirePharm.Com> Mumit, Thanks I looked at Sergey's port. He had all of those libraries as static libraries. X11R6 (win32.cf) under MSVC also builds those three libs (Xt, Xaw and XMu) as static libs. There must be some known issues that is why X Consortium builds these libs for Win32 platforms as static libs. That is what I am doing, trying to get server working Rest can be sorted out and fixed later. Suhaib From ssiddiqi@inspirepharm.com Sat Jul 17 21:51:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sat, 17 Jul 1999 21:51:00 -0000 Subject: Frame Buffer X server Message-ID: Finally, I got one Frame Buffer X server compiled under Cygwin. Now I get the error on server startup: Fatal Server error: no screens found I will play with binaries tomorrow and figure out what this error means. If anyone knows what this error is about, please e-mail me your suggestions. Suhaib From ssiddiqi@inspirepharm.com Mon Jul 19 13:29:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi, Ph.D.) Date: Mon, 19 Jul 1999 13:29:00 -0000 Subject: Need help Message-ID: <37938BB2.A6601559@inspirepharm.com> Can any one help to port approx. 200 lines of OS/2 code to Windows? It is needed for cygwin-xfree. I have no experience with OS/2 - actually never even used a OS/2 system. Thanks Suhaib From ssiddiqi@inspirepharm.com Mon Jul 19 13:40:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi, Ph.D.) Date: Mon, 19 Jul 1999 13:40:00 -0000 Subject: July 5th snapshot Message-ID: <37938E18.CCEFBB4@inspirepharm.com> With July 5th snapshot and gcc-2.95 sometimes I see an error in bash window (error pi_signal 1000 killed -- something like that). It appears only when I am compiling a very large project like Xfree86. Also sometimes when I hit control+c to kill the make, my Makefiles get corrupted, and I had to restart from scratch, i.e. make World to regenrate dependencies and Makefiles. Suhaib From earnie_boyd@yahoo.com Mon Jul 19 14:30:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Mon, 19 Jul 1999 14:30:00 -0000 Subject: July 5th snapshot Message-ID: <19990719213043.24391.rocketmail@web103.yahoomail.com> --- "Suhaib M. Siddiqi, Ph.D." wrote: > With July 5th snapshot and gcc-2.95 sometimes I see an error > in bash window (error pi_signal 1000 killed -- something like that). > It appears only when I am compiling a very large project like Xfree86. > > Also sometimes when I hit control+c to kill the make, my Makefiles > get corrupted, and I had to restart from scratch, i.e. make World > to regenrate dependencies and Makefiles. > > Suhaib > try: SET CYGWIN=nontsec There seems to be a bug with Corina's security code. I've been testing for Chris and this is what has been discovered. I suggest using the 19990717 snapshot as well as some of the problems have been fixed with this but not all. === Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > (If you respond to the list, then please don't cc me) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From ssiddiqi@inspire.InspirePharm.Com Mon Jul 19 14:33:00 1999 From: ssiddiqi@inspire.InspirePharm.Com (Suhaib M. Siddiqi) Date: Mon, 19 Jul 1999 14:33:00 -0000 Subject: July 5th snapshot Message-ID: <199907192137.RAA08919@inspire.InspirePharm.Com> Thanks Ernie :-) Suhaib From ssiddiqi@inspirepharm.com Mon Jul 19 18:18:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Mon, 19 Jul 1999 18:18:00 -0000 Subject: A short update Message-ID: This just a short update on cygwin-xfree porting project. I have created a new Arch in Xserver/hw/xfree86/os-supported/cygwin named cygwinArchitect. I researched the history of XFree86 port to OS/2 during last couple weeks. The idea of creating a Cygwin specific architect (cygwinArchitect) came from XFree86/OS2. This allowed me to fix a lot of problems. The Imake.cf in xc/config/cf now contains #ifdef __CYGWIN__ #define cygwinArchitect #define i386Architect #endif This picks the right code from hw/xfree86/os-supported/cygwin. Previously I was using #define linuxArchitect, which picking up a lot of Linux Kernel related header files and causing problems. Now I am down to only approx. 10 C sources files which needs to fixed, and a few *.s files which are giving problems when using gcc -E. I am spending most of my spare time on cygwin-xfree. I hope to get a preliminary functional X-server in near future. I have not updated the cygwin-xfree source tree since last month, because I was on daily basis doing changes to code. I will update the cygwin-xfree source tree this week, and also provide a a diff file against Xfree86 3.3.3.1. Suhaib From Ssiddiqi@InspirePharm.Com Tue Jul 20 03:54:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Tue, 20 Jul 1999 03:54:00 -0000 Subject: A short update References: <3793D729.A42242D9@ibm.net> Message-ID: Hi John, Yes, DirectX is a good target for cygwin-xfree. DirectX/XGGI/GGI is a good target. You had been working on this project, therefore I prefer you provide the updates on DirectX target. > -----Original Message----- > From: John Fortin [ mailto:fortinj@ibm.net ] > Sent: Monday, July 19, 1999 9:56 PM > To: Suhaib M. Siddiqi > Subject: Re: A short update > > > Hi Suhaib, > > Are you still focusing on XGGI/glide version?? I have the > directX SDK > ported over, so now I am learning how to use it. I plan on a creating a > DirectX target for GGI, hopefully in the near future. Then An XGGI (?) > server.. > > Thanks, > John > > "Suhaib M. Siddiqi" wrote: > > > > This just a short update on cygwin-xfree porting project. > > > > I have created a new Arch in > Xserver/hw/xfree86/os-supported/cygwin named > > cygwinArchitect. I researched the history of XFree86 port to OS/2 > > during last couple weeks. The idea of creating a Cygwin specific > > architect (cygwinArchitect) came from XFree86/OS2. This allowed me > > to fix a lot of problems. > > The Imake.cf in xc/config/cf now contains > > > > #ifdef __CYGWIN__ > > #define cygwinArchitect > > #define i386Architect > > #endif > > > > This picks the right code from hw/xfree86/os-supported/cygwin. > Previously > > I was using #define linuxArchitect, which picking up a lot of Linux > > Kernel related header files and causing problems. > > > > Now I am down to only approx. 10 C sources files which needs to > fixed, and a > > few *.s > > files which are giving problems when using gcc -E. > > > > I am spending most of my spare time on cygwin-xfree. I hope to get a > > preliminary > > functional X-server in near future. I have not updated the cygwin-xfree > > source tree since last month, because I was on daily basis doing > > changes to code. I will update the cygwin-xfree source tree > this week, and > > also > > provide a a diff file against Xfree86 3.3.3.1. > > > > Suhaib > From Ssiddiqi@InspirePharm.Com Fri Jul 23 12:53:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Fri, 23 Jul 1999 12:53:00 -0000 Subject: XFree86/Cygwin Message-ID: Here is the latest news. I have patched the Xfree86 3.3.4 code that now it compiles under Cygwin, using gcc-2.95. The X-servers for different cards compile. I could test only Voodoo3 because that is the only card I have. I have sent a note to Chris Faylor, about updating the cygwin-xfree sources and also uploading new binaries. John, we still need you DirectX. DirectX will be the best server for Windows, because it will be hardware independent. Suhaib bash-2.02$ ./XF86_SVGA XFree86 Version 3.3.4 / X Window System (protocol Version 11, revision 0, vendor release 6300) Release Date: July 13 1999 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ ) Operating System: Cygwin Cygnus Solutions Configured drivers: SVGA: server for SVGA graphics adaptors (Patchlevel 0): NV1, STG2000, RIVA 128, RIVA TNT, RIVA TNT2, RIVA ULTRA TNT2, RIVA VANTA, RIVA ULTRA VANTA, RIVA INTEGRATED, ET4000, ET4000W32, ET4000W32i, ET4000W32i_rev_b, ET4000W32i_rev_c, ET4000W32p, ET4000W32p_rev_a, ET4000W32p_rev_b, ET4000W32p_rev_c, ET4000W32p_rev_d, ET6000, ET6100, et3000, pvga1, wd90c00, wd90c10, wd90c30, wd90c24, wd90c31, wd90c33, gvga, ati, sis86c201, sis86c202, sis86c205, sis86c215, sis86c225, sis5597, sis5598, sis6326, sis530, sis620, tvga8200lx, tvga8800cs, tvga8900b, tvga8900c, tvga8900cl, tvga8900d, tvga9000, tvga9000i, tvga9100b, tvga9200cxr, tgui9400cxi, tgui9420, tgui9420dgi, tgui9430dgi, tgui9440agi, cyber9320, tgui9660, tgui9680, tgui9682, tgui9685, cyber9382, cyber9385, cyber9388, cyber9397, cyber9520, cyber9525, 3dimage975, 3dimage985, cyber9397dvd, blade3d, cyberblade, clgd5420, clgd5422, clgd5424, clgd5426, clgd5428, clgd5429, clgd5430, clgd5434, clgd5436, clgd5446, clgd5480, clgd5462, clgd5464, clgd5465, clgd6205, clgd6215, clgd6225, clgd6235, clgd7541, clgd7542, clgd7543, clgd7548, clgd7555, clgd7556, ncr77c22, ncr77c22e, cpq_avga, mga2064w, mga1064sg, mga2164w, mga2164w AGP, mgag200, mgag100, mgag400, oti067, oti077, oti087, oti037c, al2101, ali2228, ali2301, ali2302, ali2308, ali2401, cl6410, cl6412, cl6420, cl6440, video7, ark1000vl, ark1000pv, ark2000pv, ark2000mt, mx, realtek, s3_virge, AP6422, AT24, AT3D, s3_svga, NM2070, NM2090, NM2093, NM2097, NM2160, NM2200, ct65520, ct65525, ct65530, ct65535, ct65540, ct65545, ct65546, ct65548, ct65550, ct65554, ct65555, ct68554, ct69000, ct64200, ct64300, mediagx, V1000, V2x00, p9100, spc8110, i740, i740_pci, Voodoo Banshee, Voodoo3, generic From Ssiddiqi@InspirePharm.Com Fri Jul 23 14:20:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Fri, 23 Jul 1999 14:20:00 -0000 Subject: xerver and mouse Message-ID: I compiled finally compiled the XFree86 for various hardware. I disabled the mouse protocols because they are supported by OS on Windows. Now X server is searching for a mouse protocol entry in XF86Config. If I comment out the mouse protocols entries in XF86Config file, server will complain about a missing "mouse protocol" in XF86Config and will die. Does anyone know how to workaround this problem? On some Unices workstation you can compile XFree86 with -DMOUSE_PROCOL_IN_KERNEL, but I do not know how what kind of mouse protocol entry they put in XF86Config. Anyone knows about it? Suhaib bash-2.02$ ./XF86_AGX XFree86 Version 3.3.4 / X Window System (protocol Version 11, revision 0, vendor release 6300) Release Date: July 13 1999 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ ) Operating System: Cygwin Cygnus Solutions Configured drivers: AGX: Accelerated server for AGX graphics adaptors (Patchlevel 0) XF86Config: /etc/XF86Config (**) stands for supplied, (--) stands for probed/default values Config Error: /etc/XF86Config:126 Protocol "" ^^ Mouse type not supported by this OS From Ssiddiqi@InspirePharm.Com Sat Jul 24 12:06:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Sat, 24 Jul 1999 12:06:00 -0000 Subject: Xfree updated Message-ID: I have updated the source code of XFree86, and binaries. Attached is the ReadMe file for Cygwin-Xfree. This is patched source of XFree86 3.3.4 for Cygwin B20.1 The code patches, and binaries are available at ftp://sourceware.cygnus.com/pub/cygwin/xfree . Please ignore the pre-alpha-cygwin-cygwin.tar.bz2 and pre-alpga-cygwin-xfree-patch.tar.bz2. They are old files and will be deleted soon. The name of the binary file with the latest libs and x-server is pre-alpha-xfree-cygwin-b20.1.tar.bz2 (dated July 24, 1999). Fixes to cygwin-xfree servers are highly appreciated. Regards Suhaib ----Read Me--------------------------- This is a pre-Alpha version of port of X-server for Cygwin B20.1, based upon XFree86 3.3.4. To compile, you must download xc-1.tar.bz2, xc-2.tar.bz2 and xc-3.tar.bz2 If you already have XFr86-3.3.4 source code from http://www.xfree86.org , then you can download the patches file, cygwin-xfree-diff.tar.bz2. Uncompress (bunzip2) and copy the "cygwin" directory to xc/programs/Xserver/hw/xfree86/os-support. After that apply the cygwin-xfree patch; patch -p0 . You will need libcrypt.a. You can doiwnload libcrypt-cygwin-b20.1.tar.bz2. Install the libcrypt.a in ../H-i586-cygwin32/i586-cygwin32/lib. After extracting xc-1.tar.bz2, xc-2.tar.bz2, and xc-3.tar.bz2 in an "xc" directory, type "make World >& World.log" You can substantially reduce the compilation time by compiling only the X-server drivers you need, i.e change all the "#define XF86xxxServer YES" to NO, except the only you need. On my 500 MHz PIII PC/Windows Nt 4.0 SP5, compiling XFree86/Cygwin took 2 1/2 hours. My precompiled binaries of libraries and executables are in "pre-alpha-xfree-cygwin.tar.bz2." These binaries were compiled using GCC-2.95 latest snapshot from Mumit Khan and Cygwin July 17th, 199 snapshot. To use these binaries you will at least need the cygwin1.dll from July 17th, 1999 snapshot of Cygwin. Known Problems: 1) DPMSExtensions does not buoild at the moment. If you wish to work on DPMSExtensions, have a look at xc/config/cf/host.def site.def and cygwin.cf. Change BuildDPMSExtension to YES. 2) Due to the lack of DPMSExtension, drivers for GLINT and P9000 do not compile. If you wish to compile GLINT and P9000 drivers, change the following in xc/config/cf/xfree86.cf and site.def to YES #ifndef XF86P9000Server #define XF86P900Server NO #endif #ifndef XF86GLINTServer #define XF86GLINTServer NO #endif 3) The samples of XF86Config and other configuration files for /etc /dev and /var are in extra-cygwin-xfree.tar.gz2 4) The code in xc/programs/Xserver/hw/xfree86/cygwin is a very dirty (silly) hack. It needs work. If you are willing to clean up thee code in xc/programs/Xserver/hw/xfree86/cygwin, please do so. I will appreciate it. 5)XServer attempts to open /dev/console, which does not exists on Winodws. We need to find a work around for it. The source code for /dev/console is in xc/programs/Xserver/hw/xfree86/cygwin, xc/programs/Xserver/hw/xfree86/common and xc/programs/Xserver/hw/xfree86/common_hw. 6) I got XF86_SVGA.exe, X-server open an Xterm on my PC, only a few times, but most of the times, it crashed on me. 7) The Virtual Frame Buffer X-server (Xvfb.exe) compiles, but fails to display. You can read more about VFB in xc/programs/Xserver/hw/vfb/Redame. VFB usually used by X11 developers for testing X-Servers and X11 clients. It is not meant to be stand-alone X-server for end-users. Suhaib (ssiddiqi@inspirepharm.com) From ssiddiqi@inspirepharm.com Sun Jul 25 08:45:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 25 Jul 1999 08:45:00 -0000 Subject: Problem... References: <004a01bed64c$0e5a73a0$42483b80@EEDESIGN5> Message-ID: > Dear Suhaib, > > I'm lucky to be one of the first several people > who downloaded your most recent update. However, > I have a very basic problem on this great achievement: > how to start this xserver ? It seems that startx > script won't work and system will always report: > > _X11TransSocketINETConnect: Can't connect: errno = 111 > > Then I tried to run xggi directly, but there is one > dll missing: libgg-0-0-6.dll. This version although has XGGI.exe in the binary archive, but XGGI.exe is certainly non-functional, until John Fortin completes his DirectX support. The startx does work. On the bash prompt type sh startx, but there is no gaurantee that X-server will come-up. The snapshot of the sources and binaries are meant for developers and users who wish to help fix the bugs. The source code compiles and produces the executables for all the XFree86 supported drivers, but most (almost all of them) usually crash with tty errors. I am now at the point where the XFree86 source code can be compiled under Cygwin, and I am sure in near future I will fix the remaining bugs, which cause crashes. At the moment patched source code contains some dirty hacks so it, at least, compiles, which in my opinion will help to trace the problems and fix them. If you wish to try XGGI, you will need at least GGI DLLs. The source code of GGI for Cygwin is also at the Sourceware server, but it has no DirectX and Glide support. I am waiting for John Fortin's work on DirectX, after that we will release the complete source code of GGI, and precompiled DDLs. You can also test X-server binaries ( mostly likely they will crash on you) by cd' ing to /usr/X11R6/bin and typing ./XF86_SVGA or whatever other driver you wish to test. I usually test the X-server binaries by starting a commerical X-server (e.g Exceed) at Display 127.0.0.1:0.0 then attempt to start another X-server at the Display :1 and open the client at Display :1, e.g ./xterm -display 127.0.0.1:1 Regards Suhaib PS: Please direct the questions, comments and suggestions regarding Cygwin-xfree to cygwin-xfree@sourceware.cygnus.com mailing list. > > Could you help me with this problem ? > > Thanks ! > _________________________________________________________________ > /\ \ > \| ZHUANG Hao www.ctr.columbia.edu/~jerrey | > | -------------------------------------------------------------- | > | Electrical Engineering : 526 W112th Street, Apt 62 | > | Columbia University : New York, NY 10025 | > | Tel: 212-932-1689 (H) : ICQ UIN: 19613067 | > | _______________________________________________________________|_ > \/________________________________________________________________/ > From ssiddiqi@inspirepharm.com Sun Jul 25 14:38:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 25 Jul 1999 14:38:00 -0000 Subject: FW: DirectX port Message-ID: Hi Suhaib, Just a quick update... I couple of things I though were going to be easy, were not so easy. I had forgotten that since this is working in a windows environment, it needs to behave properly (ala other windows programs) and be able to recover itself, if another application runs. I have the basic framework worked out, but I need to flesh out the basic initialization, and then the interface into GGI. Unfortunately, with the new baby, time has been somewhat limited. I also posted my initial DirectX sdk port to cygwin. It is at : http://pws.prserv.net/thefortins/cyg-directx.html I, again, can't post to the cygnus maillists, so I may have to ask you to forward things as needed. Regards, John From ssiddiqi@inspirepharm.com Mon Jul 26 07:40:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Mon, 26 Jul 1999 07:40:00 -0000 Subject: Device drivers for XFree86 Message-ID: <379C7460.2111BD34@inspirepharm.com> We need a few device drivers to have XFree86 servers up and runing. I need help and advice, both, on handeling this problem. Below is a note from XFree86/Os-2 porting project. Which explains how they handle the missing device drivers. Unfortunately, they do not'provide source code of XF85SUP.SYS. Any ideas? Or, any one willing to help? Thanks Suhaib -------------- XF86SUP.SYS: This driver is a helper driver for the XFree86/OS2 project. Note this is NOT XFree86/OS2 itself. This driver offers some features which were missing in OS/2 before or were available inefficiently only. You can download the latest driver from here. It is a multiple device driver containing the following sub-devices: /dev/pmap$ gives you access to the physical memory of the PC. Warning: you should never use this to access the main RAM memory, as this could cause severe damage to the integrity of data managed by the OS/2 system (I once managed to crash the system this way and this corrupted the system so severely that I needed to re-install), but only to access adapter memory (data acquisition cards or aperture video memory) which you know for sure that OS/2 does not know or manage it itself. Required for Xservers for instance. /dev/fastio$ allows a fast method - the fastest possible - of getting access to I/O ports. Required for XFree86/OS2 for instance. /dev/tty[pq][0-f], /dev/pty[pq][0-f], /dev/ptms$ These are drivers that closely emulate 4.4BSD pseudo-TTY drivers (PTYs); such drivers are required to get xterm and xdm for XFree86/OS2 running. Also a future version of Emacs for OS/2 will take advantage of these devices. /dev/console$ This emulates a Unix style /dev/console device. This understands the TIOCCONS ioctl and other BSD ioctls. Also the PTYs may grab the console (required for xterm -C and xconsole). A spinoff of the XFree86/OS2 project and my research on SES is the following code: A function in the recent version of the xf86sup.sys driver that implements the "kill -9" feature of Unix (Fixpack 17 required). Get the recent driver, API and sample code (xf86sup.sys binaries only). In Warp3, FP38, a kernel bug prevents this feature to work. This is supposedly fixed in FP40. For now, a workaround is to use the DOSCALL1.DLL from FP37 to get the feature again. From Ssiddiqi@InspirePharm.Com Mon Jul 26 11:58:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Mon, 26 Jul 1999 11:58:00 -0000 Subject: FW: XFree86 Port (Message from XFree86/OS2 developer) Message-ID: This is for users, may be you will find it informative. Xterm, xdm etc are the issue because Cygwin support TTY. After spending a couple hours on Internet I found 3 freeware drivers for Windows which do I/O, and memory maping what he is describing in his message as a must for XFree86 server to run. Suhaib > > Hi, > Compiling the stuff with Cygnus GNU or even better with EMX and RSX, is > as you correctly found out, not the real problem with the port. > XF86SUP.SYS is the essential part of the port. This is not only the > mentioned fastio and pmap devices, but also (for xconsole and xterm) a > rather complete Unix TTY/PTY/Console emulation. If you neglect xterm, > xdm and xconsole for a while, infact your showstoppers are fastio and > pmap. > To explain what they do: > pmap allows to map arbitrary physical memory into the X server's address > space. I don't know cygwin enough to know whether there is a working > mmap/munmap Unix call available, if so, it must be capable of accessing > and mapping not only files and virtual memory pages into memory, but also > physical memory. I doubt that this will work without the help of a device > driver in NT, because the ability to access - even read/write - arbitrary > memory from a user process in NT is the worst security leak ever > possible - > even with OS/2 and a lack of security protection this is > impossible without > driver assistance. > fastio is a real hack. As you might have found out, there are several > inline assembler portions in the server code which directly access I/O > ports. If you go through a (possible in theory) kernel mechanism > to emulate > I/O accesses - the EMX library provides such a method in OS/2 - then you > will slow down these critical parts of the code (that's why they are > assembler!) by one or two orders of magnitude. The Unix ports > have the same > problem, and the trick I built into fastio is comparable to the way it was > solved in Unix. The processor has two bits IOPL in its EFLAGS CPU > register, > which control a fence of privilege below which I/O accesses and some other > instructions in user mode won't trap. OS/2 by default sets this > to 2, meaning > the user processes running in ring 3, won't be allowed to do I/O. fastio > is a small ring 0 code (which is capable to alter these bits - user code > can't) which is called at task time by the X server to modify its own > per-process copy of the EFLAGS register. This should also be possible > for NT, with the help of a small driver. > > Hope this helps, if not feel free to ask again > Holger > > -- > Signature fault - code dumbed > From Ssiddiqi@InspirePharm.Com Mon Jul 26 15:07:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Mon, 26 Jul 1999 15:07:00 -0000 Subject: IOPL Message-ID: I am getting the following error from X-server, as expected according to Holger(the person who ported XFree86 to OS/2). Fatal server error: xf86EnablePortIO: Failed to get IOPL for I/O Program exited with code 01. Any suggestions on how to handle it? I did find a source code and also compiled driver for maping I/O port on Windows. Maybe someone will have another suggestion on it. Suhaib -------This from the author of XFree86/OS2 about I/O ports--- As you might have found out, there are several inline assembler portions in the server code which directly access I/O ports. If you go through a (possible in theory) kernel mechanism to emulate I/O accesses - the EMX library provides such a method in OS/2 - then you will slow down these critical parts of the code (that's why they are assembler!) by one or two orders of magnitude. The Unix ports have the same problem, and the trick I built into fastio is comparable to the way it was solved in Unix. The processor has two bits IOPL in its EFLAGS CPU register, which control a fence of privilege below which I/O accesses and some other instructions in user mode won't trap. OS/2 by default sets this to 2, meaning the user processes running in ring 3, won't be allowed to do I/O. fastio is a small ring 0 code (which is capable to alter these bits - user code can't) which is called at task time by the X server to modify its own per-process copy of the EFLAGS register. This should also be possible for NT, with the help of a small driver. From earnie_boyd@yahoo.com Mon Jul 26 15:14:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Mon, 26 Jul 1999 15:14:00 -0000 Subject: FW: XFree86 Port (Message from XFree86/OS2 developer) Message-ID: <19990726221443.21342.rocketmail@web103.yahoomail.com> --- "Suhaib M. Siddiqi" wrote: > This is for users, may be you will find it informative. > Xterm, xdm etc are the issue because Cygwin support TTY. > > After spending a couple hours on Internet I found 3 freeware drivers > for Windows which do I/O, and memory maping what he is describing in his > message > as a must for XFree86 server to run. > > Suhaib > > > > > Hi, > > Compiling the stuff with Cygnus GNU or even better with EMX and RSX, is > > as you correctly found out, not the real problem with the port. > > XF86SUP.SYS is the essential part of the port. This is not only the > > mentioned fastio and pmap devices, but also (for xconsole and xterm) a > > rather complete Unix TTY/PTY/Console emulation. If you neglect xterm, > > xdm and xconsole for a while, infact your showstoppers are fastio and > > pmap. > > To explain what they do: > > pmap allows to map arbitrary physical memory into the X server's address > > space. I don't know cygwin enough to know whether there is a working > > mmap/munmap Unix call available, if so, it must be capable of accessing Both of these call are supported by the cygwin library. === Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > (If you respond to the list, then please don't cc me) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From ssiddiqi@inspirepharm.com Mon Jul 26 17:28:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Mon, 26 Jul 1999 17:28:00 -0000 Subject: FW: XFree86 Port (Message from XFree86/OS2 developer) References: <19990726221443.21342.rocketmail@web103.yahoomail.com> Message-ID: > > > To explain what they do: > > > pmap allows to map arbitrary physical memory into the X > server's address > > > space. I don't know cygwin enough to know whether there is a working > > > mmap/munmap Unix call available, if so, it must be capable of > accessing > > Both of these call are supported by the cygwin library. > Hi Ernie, Thanks. Actually below is my code, which i named cygwin_mmap.c in xfree86/os-support/cygwin. The Server returns an IOPL I/O error. Obviously I am doing something wrong; that how do we handle the issue of /dev/iopl, which is hard-coded at several places in XFree86 source code. Any advice, please? Thanks Suhaib -------------------- #include "X.h" #include "misc.h" #define DevicePtr int #include "xf86_OSlib.h" #define BIOS_SIZE 0x20000 #define KERN_SUCCESS 0 int xf86ReadBIOS(Base, Offset, Buf, Len) unsigned long Base; unsigned long Offset; unsigned char *Buf; int Len; { int fd; int screen_addr; int ret; if ((fd = open("/dev/iopl", O_RDWR, 0)) < 0) { ErrorF("xf86ReadBIOS: Failed to open /dev/iopl\n"); return(-1); } if (KERN_SUCCESS != vm_allocate(task_self(), &screen_addr, BIOS_SIZE, TRUE)) { ErrorF("xf86ReadBIOS: Failed vmallocate %x\n", BIOS_SIZE); close(fd); return(-1); } if (mmap(screen_addr, BIOS_SIZE, 3, 1, fd, Base) < 0) { ErrorF("xf86ReadBIOS: Failed to mmap %x at %x\n", BIOS_SIZE, Base); vm_deallocate(task_self(), screen_addr, BIOS_SIZE); close(fd); return(-1); } memcpy(Buf, (unsigned char *)(screen_addr + Offset), Len); if (KERN_SUCCESS != vm_deallocate(task_self(), screen_addr, BIOS_SIZE)) { ErrorF("xf86ReadBIOS: Failed vmdeallocate %x\n", BIOS_SIZE); close(fd); return(-1); } close(fd); return(Len); } From earnie_boyd@yahoo.com Mon Jul 26 17:50:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Mon, 26 Jul 1999 17:50:00 -0000 Subject: FW: XFree86 Port (Message from XFree86/OS2 developer) Message-ID: <19990727005022.3123.rocketmail@web103.yahoomail.com> Just guessing at this; but, is the /dev/iopl supported in the device emulation by cygwin? If not, you'll have to add it to the device emulation routines in the code in the winsup directory for cygwin. Earnie. --- "Suhaib M. Siddiqi" wrote: > > > > > To explain what they do: > > > > pmap allows to map arbitrary physical memory into the X > > server's address > > > > space. I don't know cygwin enough to know whether there is a working > > > > mmap/munmap Unix call available, if so, it must be capable of > > accessing > > > > Both of these call are supported by the cygwin library. > > > > Hi Ernie, > > Thanks. Actually below is my code, which i named cygwin_mmap.c in > xfree86/os-support/cygwin. The Server returns > an IOPL I/O error. Obviously I am doing something wrong; that how do we > handle > the issue of /dev/iopl, which is hard-coded at several places in XFree86 > source code. > Any advice, please? > Thanks > Suhaib > -------------------- > #include "X.h" > #include "misc.h" > > #define DevicePtr int > #include "xf86_OSlib.h" > > #define BIOS_SIZE 0x20000 > #define KERN_SUCCESS 0 > > int xf86ReadBIOS(Base, Offset, Buf, Len) > unsigned long Base; > unsigned long Offset; > unsigned char *Buf; > int Len; > { > int fd; > int screen_addr; > int ret; > > if ((fd = open("/dev/iopl", O_RDWR, 0)) < 0) > { > ErrorF("xf86ReadBIOS: Failed to open /dev/iopl\n"); > return(-1); > } > if (KERN_SUCCESS != vm_allocate(task_self(), &screen_addr, > BIOS_SIZE, TRUE)) > { > ErrorF("xf86ReadBIOS: Failed vmallocate %x\n", BIOS_SIZE); > close(fd); > return(-1); > } > if (mmap(screen_addr, BIOS_SIZE, 3, 1, fd, Base) < 0) > { > ErrorF("xf86ReadBIOS: Failed to mmap %x at %x\n", > BIOS_SIZE, Base); > vm_deallocate(task_self(), screen_addr, BIOS_SIZE); > close(fd); > return(-1); > } > memcpy(Buf, (unsigned char *)(screen_addr + Offset), Len); > if (KERN_SUCCESS != vm_deallocate(task_self(), screen_addr, BIOS_SIZE)) > { > ErrorF("xf86ReadBIOS: Failed vmdeallocate %x\n", BIOS_SIZE); > close(fd); > return(-1); > } > close(fd); > return(Len); > } > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From ssiddiqi@inspirepharm.com Mon Jul 26 18:04:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Mon, 26 Jul 1999 18:04:00 -0000 Subject: FW: XFree86 Port (Message from XFree86/OS2 developer) References: <19990727005022.3123.rocketmail@web103.yahoomail.com> Message-ID: > Just guessing at this; but, is the /dev/iopl supported in the > device emulation > by cygwin? If not, you'll have to add it to the device emulation > routines in > the code in the winsup directory for cygwin. > > Earnie. Ernie, no, it is not supported by cygwin, that is /dev/iopl, unless I am missing something. That is what Holger meant when he talked about mmap/munmap. Mmap and munmap is in Cygwin, but dunno how it relates to /dev/iopl. I had been studying the codes which handle /dev/iopl on Unices. Below is a sample from GNU MACH. The /dev/iopl is hard coded at 1000s times to access all kinf memories (video blah blah). Holger suggested, writing a small device driver which read the physical memory and using his OS/2 code in XFree86. First I was stuck with /dev/mouse, but that was an easy one to resolve. Regards Suhaib #ifdef MACH386 static int ioplfd = -1; static Bool ScreenEnabled[MAXSCREENS]; static Bool IOEnabled = FALSE; static Bool InitDone = FALSE; #endif void xf86ClearIOPortList(ScreenNum) int ScreenNum; { #ifdef MACH386 int i; if (!InitDone) { for (i = 0; i < MAXSCREENS; i++) ScreenEnabled[i] = FALSE; InitDone = TRUE; } #endif return; } /* ARGSUSED */ void xf86AddIOPorts(ScreenNum, NumPorts, Ports) int ScreenNum; int NumPorts; unsigned *Ports; { return; } void xf86EnableIOPorts(ScreenNum) int ScreenNum; { #ifdef MACH386 ScreenEnabled[ScreenNum] = TRUE; if (IOEnabled) return; if ((ioplfd = open("/dev/iopl", 0)) < 0) FatalError("xf86EnablePortIO: Failed to get IOPL for I/O\n"); IOEnabled = TRUE; #endif /* MACH386 */ return; } > --- "Suhaib M. Siddiqi" wrote: > > > > > > > To explain what they do: > > > > > pmap allows to map arbitrary physical memory into the X > > > server's address > > > > > space. I don't know cygwin enough to know whether there > is a working > > > > > mmap/munmap Unix call available, if so, it must be capable of > > > accessing > > > > > > Both of these call are supported by the cygwin library. > > > > > > > Hi Ernie, > > > > Thanks. Actually below is my code, which i named cygwin_mmap.c in > > xfree86/os-support/cygwin. The Server returns > > an IOPL I/O error. Obviously I am doing something wrong; that how do we > > handle > > the issue of /dev/iopl, which is hard-coded at several places in XFree86 > > source code. > > Any advice, please? > > Thanks > > Suhaib > > -------------------- > > #include "X.h" > > #include "misc.h" > > > > #define DevicePtr int > > #include "xf86_OSlib.h" > > > > #define BIOS_SIZE 0x20000 > > #define KERN_SUCCESS 0 > > > > int xf86ReadBIOS(Base, Offset, Buf, Len) > > unsigned long Base; > > unsigned long Offset; > > unsigned char *Buf; > > int Len; > > { > > int fd; > > int screen_addr; > > int ret; > > > > if ((fd = open("/dev/iopl", O_RDWR, 0)) < 0) > > { > > ErrorF("xf86ReadBIOS: Failed to open /dev/iopl\n"); > > return(-1); > > } > > if (KERN_SUCCESS != vm_allocate(task_self(), &screen_addr, > > BIOS_SIZE, TRUE)) > > { > > ErrorF("xf86ReadBIOS: Failed vmallocate %x\n", BIOS_SIZE); > > close(fd); > > return(-1); > > } > > if (mmap(screen_addr, BIOS_SIZE, 3, 1, fd, Base) < 0) > > { > > ErrorF("xf86ReadBIOS: Failed to mmap %x at %x\n", > > BIOS_SIZE, Base); > > vm_deallocate(task_self(), screen_addr, BIOS_SIZE); > > close(fd); > > return(-1); > > } > > memcpy(Buf, (unsigned char *)(screen_addr + Offset), Len); > > if (KERN_SUCCESS != vm_deallocate(task_self(), screen_addr, > BIOS_SIZE)) > > { > > ErrorF("xf86ReadBIOS: Failed vmdeallocate %x\n", BIOS_SIZE); > > close(fd); > > return(-1); > > } > > close(fd); > > return(Len); > > } > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From khan@xraylith.wisc.EDU Mon Jul 26 18:19:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Mon, 26 Jul 1999 18:19:00 -0000 Subject: FW: XFree86 Port (Message from XFree86/OS2 developer) References: Message-ID: <199907270010.TAA03651@mercury.xraylith.wisc.edu> "Suhaib M. Siddiqi" writes: > > Ernie, no, it is not supported by cygwin, that is /dev/iopl, unless > I am missing something. That is what Holger meant when he talked about > mmap/munmap. Mmap and munmap is in Cygwin, but dunno how it relates to > /dev/iopl. I had been studying the codes which handle /dev/iopl on Unices. > Below is a sample from GNU MACH. The /dev/iopl is hard coded at 1000s times > to access all kinf memories (video blah blah). Holger suggested, writing a > small > device driver which read the physical memory and using his OS/2 code in > XFree86. /dev/iopl is a *very* Linux specific thing, and it essentially allows you to map io ports to memory regions (or something like that). Needs to be followed by call to iopl(), another linux specific routine, to change the I/O privilege level that allows the access the FIFO ports. As far as I know, it's only needed for 8514 servers, but I haven't looked at this stuff for years, so quite out of date. I believe you'll need to look at win32 api to start adding these in since Cygwin doesn't wrap it. Unfortunately, my knowledge of win32 api is very limited, and can't be of much help here. Regards, Mumit From bianchi@www.arte.unipi.it Mon Jul 26 23:59:00 1999 From: bianchi@www.arte.unipi.it (Federico Bianchi) Date: Mon, 26 Jul 1999 23:59:00 -0000 Subject: IOPL, physical memory mapping and the likes. Message-ID: Looking at the current thread of discussion (/dev/iopl and its implications) made me remind some things about 9x and NT which may be of interest to some of you - more than a year ago, in fact, I had a contract with a college department which involved giving full permissions to DOS (DPMI) programs under NT. Access to either I/O ports or physical memory under 9x is not really an issue; in the latter case you have to know where VMM maps the requested area or to do the mapping yourself - and changing the IOPM, should it really be necessary, is a snap. NT is quite different: first of all, there is no way to directly modify your descriptor tables or IOPM - unless, of course, you are running at kernel level (i.e., unless you are a KMD/WDM) I know of the following pieces of code which may be of help: - MapMem.sys (Micro$oft) allows you to map some memory region in your user address space - PortIO.sys (Micro$oft as well) uses DeviceIOControl calls to do non-memory mapped (port) I/O; both MapMem and PortIO come with full source in the NT DDK, and they are the recommended (Micro$oft blessed) solution to get your job done - should you really need to perform INs and OUTs, check for a package called "DirectNT", published by the German magazine C&T; it includes another package published in a DDJ issue called "TotalIO/GiveIO", and both are much interesting to read Side note: the astute reader has already noticed you _MUST_ have Administrator rights to install all of these programs, since they are kernel-mode drivers. DirectX, with all its inconsistences and its kludginess, is probably the way to go if you really need to run smoothly; an alternative might be getting your hands on the xlib over Win32 sources (I have them somewhere) and extending it to encompass all the needed functionality - this would probably be less performant, but might have a distinct advantage in the better integration with the underlying (Windows) environment. In any case, I would _STRONGLY_ advice you to get both the 98, the NT 4.0 and the NT 5.0rc1 (Win2k) DDKs - they are free and the documentation you may find in them makes them extremely worthwhile a thorough check. Best regards to you all and kudos for your (amazing) work. Federico Bianchi Dipartimento di Storia delle Arti Universita` degli Studi di Pisa p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy) tel. +39-050-587111 (cent.), +39-050-587224 (uff.) fax. +39-050-580128; e-mail: =================================================== !DISCLAIMER!: my e-mail reflects _my_own_ opinions! =================================================== PS: sorry for my English, but it's not my first language From Ssiddiqi@InspirePharm.Com Tue Jul 27 04:19:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Tue, 27 Jul 1999 04:19:00 -0000 Subject: IOPL, physical memory mapping and the likes. References: Message-ID: Hi Federico, Thanks for the informative message. I have a very limited experience with Device Drivers. Your mail certaily helps a lot. I would appreciate if you could send me the Xlib you mentioned. With best regards Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Federico > Bianchi > Sent: Tuesday, July 27, 1999 3:00 AM > To: XFree86 over CygWin mailing list > Subject: IOPL, physical memory mapping and the likes. > > > > Looking at the current thread of discussion (/dev/iopl and its > implications) made me remind some things about 9x and NT which may be of > interest to some of you - more than a year ago, in fact, I had a contract > with a college department which involved giving full permissions to DOS > (DPMI) programs under NT. > > Access to either I/O ports or physical memory under 9x is not really an > issue; in the latter case you have to know where VMM maps the requested > area or to do the mapping yourself - and changing the IOPM, should it > really be necessary, is a snap. > > NT is quite different: first of all, there is no way to directly modify > your descriptor tables or IOPM - unless, of course, you are running at > kernel level (i.e., unless you are a KMD/WDM) > > I know of the following pieces of code which may be of help: > > - MapMem.sys (Micro$oft) allows you to map some memory region in your user > address space > - PortIO.sys (Micro$oft as well) uses DeviceIOControl calls to do > non-memory mapped (port) I/O; both MapMem and PortIO come with full > source in the NT DDK, and they are the recommended (Micro$oft blessed) > solution to get your job done > - should you really need to perform INs and OUTs, check for a package > called "DirectNT", published by the German magazine C&T; it includes > another package published in a DDJ issue called "TotalIO/GiveIO", and > both are much interesting to read > > Side note: the astute reader has already noticed you _MUST_ have > Administrator rights to install all of these programs, since they are > kernel-mode drivers. DirectX, with all its inconsistences and its > kludginess, is probably the way to go if you really need to run smoothly; > an alternative might be getting your hands on the xlib over Win32 sources > (I have them somewhere) and extending it to encompass all the needed > functionality - this would probably be less performant, but might have a > distinct advantage in the better integration with the underlying (Windows) > environment. > > In any case, I would _STRONGLY_ advice you to get both the 98, the NT 4.0 > and the NT 5.0rc1 (Win2k) DDKs - they are free and the documentation you > may find in them makes them extremely worthwhile a thorough check. > > Best regards to you all and kudos for your (amazing) work. > > Federico Bianchi > Dipartimento di Storia delle Arti > Universita` degli Studi di Pisa > p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy) > tel. +39-050-587111 (cent.), +39-050-587224 (uff.) > fax. +39-050-580128; e-mail: > > =================================================== > !DISCLAIMER!: my e-mail reflects _my_own_ opinions! > =================================================== > > PS: sorry for my English, but it's not my first language > From Ssiddiqi@InspirePharm.Com Wed Jul 28 10:33:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Wed, 28 Jul 1999 10:33:00 -0000 Subject: X-Server Debug Message-ID: I am trying to debug the X-Server. It crashes. Using GDB, I get the following message (--) SVGA: Mode "320x240" needs vert refresh rate of 75.14 Hz. Deleted. Warning: No FontPath specified, using compiled-in default. (--) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Sp eedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X 11R6 /lib/X11/fonts/100dpi/" 0 0 [main] c:\usr\X11R6\bin\XF86_SVGA.exe 1033 handle_exceptions: Exce ption: STATUS_PRIVILEGED_INSTRUCTION 0 21106 [main] XF86_SVGA 1033 stackdump: Dumping stack trace to XF86_SVGA. exe.stackdump program exited with code 04. I cannot backtrace, although I compiled it with -g option. When I try to backtrace I get "No Stack". The stackdump files shows the following. Perhaps Ernie or Chris can shed some light on what this STATUS_PRIVILEGED_INSTRUCTION mean, please? Thanks Suhaib 20398 41504 [main] XF86_SVGA 1033 exception: trapped! 59524 101028 [main] XF86_SVGA 1033 exception: code 0xC0000096 at 0x50488C 46467 147495 [main] XF86_SVGA 1033 exception: ax 0x0 bx 0x0 cx 0x18 dx 0xCF8 25265 172760 [main] XF86_SVGA 1033 exception: si 0x0 di 0x0 bp 0x2DDFC24 sp 0x2DDFBFC 29611 202371 [main] XF86_SVGA 1033 exception: exception is: STATUS_PRIVILEGED_INSTRUCTION 39689 242060 [main] XF86_SVGA 1033 stack: Stack trace: 30468 272528 [main] XF86_SVGA 1033 stack: frame 0: sp = 0x2DDF9F4, pc = 0x6100B5FE 29640 302168 [main] XF86_SVGA 1033 stack: frame 1: sp = 0x2DDFA14, pc = 0x6100BA4B 40484 342652 [main] XF86_SVGA 1033 stack: frame 2: sp = 0x2DDFA54, pc = 0x77F96666 30318 372970 [main] XF86_SVGA 1033 stack: frame 3: sp = 0x2DDFA78, pc = 0x77F8912B 41349 414319 [main] XF86_SVGA 1033 stack: frame 4: sp = 0x2DDFB04, pc = 0x77F763BA 28024 442343 [main] XF86_SVGA 1033 stack: frame 5: sp = 0x2DDFC24, pc = 0x50509E 21985 464328 [main] XF86_SVGA 1033 stack: frame 6: sp = 0x2DDFD74, pc = 0x4E456B 79655 543983 [main] XF86_SVGA 1033 stack: frame 7: sp = 0x2DDFDC4, pc = 0x4C253A 38772 582755 [main] XF86_SVGA 1033 stack: frame 8: sp = 0x2DDFE24, pc = 0x4F8206 40053 622808 [main] XF86_SVGA 1033 stack: frame 9: sp = 0x2DDFE64, pc = 0x4F2874 33620 656428 [main] XF86_SVGA 1033 stack: frame 10: sp = 0x2DDFEB4, pc = 0x507305 46275 702703 [main] XF86_SVGA 1033 stack: frame 11: sp = 0x2DDFEF4, pc = 0x610046E8 40288 742991 [main] XF86_SVGA 1033 stack: frame 12: sp = 0x2DDFF60, pc = 0x67401B 39921 782912 [main] XF86_SVGA 1033 stack: frame 13: sp = 0x2DDFF90, pc = 0x40103D 48394 831306 [main] XF86_SVGA 1033 stack: frame 14: sp = 0x2DDFFC0, pc = 0x77F1BA06 33707 865013 [main] XF86_SVGA 1033 stack: frame 15: sp = 0x2DDFFF0, pc = 0x0 38155 903168 [main] XF86_SVGA 1033 stack: End of stack trace From Ssiddiqi@InspirePharm.Com Thu Jul 29 04:21:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Thu, 29 Jul 1999 04:21:00 -0000 Subject: Privileged Opcode References: Message-ID: Hi Federico, > How strange.... > > The PRIVILEGED_INSTRUCTION itself is a trap (I don't remember at hand > its INT number, but it shouldn't matter) triggered whenever an user mode > program runs ring 0 (kernel) or IOPL instructions, that is either opcodes > directly involving the privilege mechanism (e.g. LGDT or LIDT, ARPL, LTR, > etc.) or I/O related (IN*, OUT*, CLI/STI). It is comming from ..Xserver/dix library code. On line 248 in main.c the server is restarted if it was unable to obtain necessary parameters from XF86Config file. On Cygwin the restart(1) code in main.c at line 248 is causing the SIGTRAP when the server starts. For now I have disabled this feature and will recompile the server to see what happen next ;-) Thanks for looking at the code. You would be of great help if you could hack that code for Windows. Regards Suhaib From ssiddiqi@inspirepharm.com Sat Jul 31 11:35:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sat, 31 Jul 1999 11:35:00 -0000 Subject: Devices support for XFree Message-ID: I got the source of XF86SYS.SUP from Holger Veit. He wrote this driver for XFree86/OS2. This driver basically emulates all the neccessary devices under /dev on a UNIX OS. XFree86 needs access to several of these devices. He provided the source code of his SF86SYS.SUP under BSD style License. The source code of his XF86SYS.SUP drivers will be a great help in completing the XFree86 port to Cygwin. Access to UNIX like devices, was the last hurdle I was stuck since few weeks. His source code for XF86SYS.SUP was compiled with GCC 2.7.2 and contains a very few OS2 API stuff. It will be relatively easy to port XF86SYS.SUP driver to Cygwin/Win32. Suhaib