From ssiddiqi@ipass.net Wed Aug 11 14:43:00 1999 From: ssiddiqi@ipass.net (Suhaib M. Siddiqi) Date: Wed, 11 Aug 1999 14:43:00 -0000 Subject: X Locale References: <19990811173050.A1912@cygnus.com> Message-ID: Using the August 9th snapshot, I seems to have broken the xterm in X11. I get the following error: bash-2.02$ ./xterm Warning: locale not supported by C library, locale unchanged Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default Failed to open input method ./xterm: unable to find usable termcap entry. The termcap entry is there in my /etc/termcap file. The same file was working OK with Cygwin B20.1. Any suggestions, please? Suhaib From earnie_boyd@yahoo.com Wed Aug 11 19:53:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Wed, 11 Aug 1999 19:53:00 -0000 Subject: X Locale Message-ID: <19990812025313.7801.rocketmail@web135.yahoomail.com> --- "Suhaib M. Siddiqi" wrote: > > > Using the August 9th snapshot, I seems to have broken the xterm > in X11. > I get the following error: > > bash-2.02$ ./xterm > Warning: locale not supported by C library, locale unchanged > Warning: locale not supported by Xlib, locale set to C > Warning: X locale modifiers not supported, using default > Failed to open input method > ./xterm: unable to find usable termcap entry. > > > The termcap entry is there in my /etc/termcap file. The same file > was working OK with Cygwin B20.1. > > Any suggestions, please? Did you install new libraries and headers from the cygwin-inst snapshot? If you did you may have to rebuild your libraries to get things to work correctly. Although, it seems unlikely to be the cause of this problem. === 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 Thu Aug 12 03:55:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib M. Siddiqi) Date: Thu, 12 Aug 1999 03:55:00 -0000 Subject: X Locale References: <19990812025313.7801.rocketmail@web135.yahoomail.com> Message-ID: I did both, Installed the new snapshot, and also compiled the recent snapshot myself. The libraries were built again using Snapshot's libs and headers. I assume it has something to do with SnapShot because same code on other machine with Stcok B20.1 does not give these errors. Suhaib > > > > > > Using the August 9th snapshot, I seems to have broken the xterm > > in X11. > > I get the following error: > > > > bash-2.02$ ./xterm > > Warning: locale not supported by C library, locale unchanged > > Warning: locale not supported by Xlib, locale set to C > > Warning: X locale modifiers not supported, using default > > Failed to open input method > > ./xterm: unable to find usable termcap entry. > > > > > > The termcap entry is there in my /etc/termcap file. The same file > > was working OK with Cygwin B20.1. > > > > Any suggestions, please? > > Did you install new libraries and headers from the cygwin-inst > snapshot? If > you did you may have to rebuild your libraries to get things to > work correctly. > Although, it seems unlikely to be the cause of this problem. > === > 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 earnie_boyd@yahoo.com Thu Aug 12 05:41:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Thu, 12 Aug 1999 05:41:00 -0000 Subject: X Locale Message-ID: <19990812124122.14375.rocketmail@web130.yahoomail.com> Send Chris Faylor an strace. strace -f -oc:/temp/strace.xterm ./xterm bzip2 c:/temp/strace.xterm You could compare the b20.1 strace to the b21 strace to try to determine the difference yourself. In stock b20.1 you get an strace by `export CYGWIN="strace=1,c:/temp/strace.xterm $CYGWIN"' and executing the program. To turn off the strace reset the CYGWIN variable without the strace setting. Good Luck, Earnie. --- "Suhaib M. Siddiqi" wrote: > I did both, Installed the new snapshot, and also compiled the recent > snapshot myself. > The libraries were built again using Snapshot's libs and headers. > I assume it has something to do with SnapShot because same code > on other machine with Stcok B20.1 does not give these errors. > > Suhaib > > > > > > > > > > Using the August 9th snapshot, I seems to have broken the xterm > > > in X11. > > > I get the following error: > > > > > > bash-2.02$ ./xterm > > > Warning: locale not supported by C library, locale unchanged > > > Warning: locale not supported by Xlib, locale set to C > > > Warning: X locale modifiers not supported, using default > > > Failed to open input method > > > ./xterm: unable to find usable termcap entry. > > > > > > > > > The termcap entry is there in my /etc/termcap file. The same file > > > was working OK with Cygwin B20.1. > > > > > > Any suggestions, please? > > > > Did you install new libraries and headers from the cygwin-inst > > snapshot? If > > you did you may have to rebuild your libraries to get things to > > work correctly. > > Although, it seems unlikely to be the cause of this problem. > > === > > 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 > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From cgf@cygnus.com Thu Aug 12 14:41:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Thu, 12 Aug 1999 14:41:00 -0000 Subject: X Locale References: <19990812124122.14375.rocketmail@web130.yahoomail.com> Message-ID: <19990812174308.A10022@cygnus.com> No! Do not send me an strace. I am straced out. I have no interest in seeing an strace from X. Is it really too much to ask for people to actually try to debug problems like this themselves? You can either look at the strace logs yourself or run things under gdb. Alternatively, if you can provide a simple test case, I'll gladly look at it. I am *not* going to debug somebody's problems with a complicated program like strace, however. Finally, I read every message in the cygwin, cygwin-developers, and cygwin-xfree mailing lists. If I see a message that causes me concern, I'll send mail to the individual in question. There is no need to suggest to people on the public mailing list that they send me anything. If it is required, I will do so myself. -chris On Thu, Aug 12, 1999 at 05:41:22AM -0700, Earnie Boyd wrote: >Send Chris Faylor an strace. >strace -f -oc:/temp/strace.xterm ./xterm >bzip2 c:/temp/strace.xterm > >You could compare the b20.1 strace to the b21 strace to try to determine the >difference yourself. In stock b20.1 you get an strace by `export >CYGWIN="strace=1,c:/temp/strace.xterm $CYGWIN"' and executing the program. To >turn off the strace reset the CYGWIN variable without the strace setting. > >--- "Suhaib M. Siddiqi" wrote: >>I did both, Installed the new snapshot, and also compiled the recent >>snapshot myself. The libraries were built again using Snapshot's libs >>and headers. I assume it has something to do with SnapShot because >>same code on other machine with Stcok B20.1 does not give these errors. >> >>>>Using the August 9th snapshot, I seems to have broken the xterm in X11. >>>>I get the following error: >>>> >>>>bash-2.02$ ./xterm Warning: locale not supported by C library, locale >>>>unchanged Warning: locale not supported by Xlib, locale set to C >>>>Warning: X locale modifiers not supported, using default Failed to open >>>>input method ./xterm: unable to find usable termcap entry. >>>> >>>> >>>>The termcap entry is there in my /etc/termcap file. The same file was >>>>working OK with Cygwin B20.1. >>>> >>>>Any suggestions, please? >>> >>>Did you install new libraries and headers from the cygwin-inst >>>snapshot? If you did you may have to rebuild your libraries to get >>>things to work correctly. Although, it seems unlikely to be the cause >>>of this problem. From ssiddiqi@inspirepharm.com Thu Aug 12 18:07:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Thu, 12 Aug 1999 18:07:00 -0000 Subject: X Locale Message-ID: The problem with Xterm is actually related to libXt. For some unknown reasons the bugs in libXt poped up with Cygwin August 9th Snapshot. A developer from LessTif had seen similar problems on Linux and his patch never got incorporated into official X11R6.x patches. I have asked him to send me his patch. libXt is doing same thing with DDD 3.1.6 on Cygwin August 9th snapshot. With B20.1 this bug in libXt was causing problems only if a DLL version of libXt was built. With latest snapshots of Cygwin, now static libXt causes problems too. I guess I need to work on libXt, unless I get the patch from LessTif developers. Bill from Cygwin-xfree list mentioned it could be binary verses text mount. I did try his suggestion, unfortunately in this case it not mount. Using a strace and gdb, several XtCreateWidgets are causing problems... Regards Suhaib From ssiddiqi@InspirePharm.Com Mon Aug 16 05:20:00 1999 From: ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Mon, 16 Aug 1999 05:20:00 -0000 Subject: Xfree86 port Message-ID: I finally got the acceptance from XFree86 Board of Directors to join XFree86 development team. While reading the developers mail archive, which is not accessable to general public, I noticed that there is already a low pace effort underway to port XFree86 to Win32. Most of the work being done is by Cygnus (Cygwin) competitors. There were a few discussion of xfree86 patches from cygwin-xfree (sourceware.cygnus.com/pub/cygwin/xfree). Suhaib From Ssiddiqi@InspirePharm.Com Wed Aug 18 05:29:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Wed, 18 Aug 1999 05:29:00 -0000 Subject: mmaper Message-ID: XFree86 uses mmap() munmap() heavily. Somtimes a coredump with privileged_access_violation is difficult to find trace. Usage: mmap The attached simple program can be used to mmap() a portion of a file, echoing its contents to stdout, which can be handy for testing mmap(). From hicklinr@mcd.alcatel.be Wed Aug 18 10:21:00 1999 From: hicklinr@mcd.alcatel.be (Richard) Date: Wed, 18 Aug 1999 10:21:00 -0000 Subject: Imake and DLLs under Cygwin References: Message-ID: <37BAEBF8.F18EAFE@mcd.alcatel.be> > First you need to figure out the export symbols > from your code and write service-def.cpp. Yes - is there any documentation on the form of those .cpp files? From ssiddiqi@ipass.net Wed Aug 18 10:29:00 1999 From: ssiddiqi@ipass.net (Suhaib Siddiqi) Date: Wed, 18 Aug 1999 10:29:00 -0000 Subject: Imake and DLLs under Cygwin References: <37BAEBF8.F18EAFE@mcd.alcatel.be> Message-ID: There cannot be a document on *.cpp files. These files contains only export symbols. Please cc only to cygwin-xfree because many users subscribe to both the lists, i.e cygwin and cygwin-xfree and do not getting dulicate messages.. > -----Original Message----- > From: Richard [ mailto:hicklinr@mcd.alcatel.be ] > Sent: Wednesday, August 18, 1999 1:23 PM > To: Suhaib Siddiqi > Cc: cygwin-xfree@sourceware.cygnus.com; cygwin@sourceware.cygnus.com > Subject: Re: Imake and DLLs under Cygwin > > > > First you need to figure out the export symbols > > from your code and write service-def.cpp. > > Yes - is there any documentation on the form of > those .cpp files? > From Ssiddiqi@InspirePharm.Com Wed Aug 18 10:34:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Wed, 18 Aug 1999 10:34:00 -0000 Subject: Imake and DLLs under Cygwin References: <37BAEBF8.F18EAFE@mcd.alcatel.be> Message-ID: > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Richard > Sent: Wednesday, August 18, 1999 1:23 PM > To: Suhaib Siddiqi > Cc: cygwin-xfree@sourceware.cygnus.com; cygwin@sourceware.cygnus.com > Subject: Re: Imake and DLLs under Cygwin > > > > First you need to figure out the export symbols > > from your code and write service-def.cpp. > > Yes - is there any documentation on the form of > those .cpp files? > You can look at X11-def.cpp as an example in xfree source tree. Suhaib From hicklinr@mcd.alcatel.be Wed Aug 18 10:43:00 1999 From: hicklinr@mcd.alcatel.be (Richard) Date: Wed, 18 Aug 1999 10:43:00 -0000 Subject: Imake and DLLs under Cygwin References: Message-ID: <37BAF11B.8900C80C@mcd.alcatel.be> > You can look at X11-def.cpp as an example in xfree source tree. I'm downloading now ... From Ssiddiqi@InspirePharm.Com Wed Aug 18 10:57:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Wed, 18 Aug 1999 10:57:00 -0000 Subject: Imake and DLLs under Cygwin References: <37BAF11B.8900C80C@mcd.alcatel.be> Message-ID: Good luck. But please do not assume that X-server is that code is functional. It is under development, and if you are willing to help to finish this project, your help will be appreciated. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Richard > Sent: Wednesday, August 18, 1999 1:45 PM > To: Suhaib Siddiqi > Cc: cygwin-xfree@sourceware.cygnus.com > Subject: Re: Imake and DLLs under Cygwin > > > > You can look at X11-def.cpp as an example in xfree source tree. > > I'm downloading now ... > From hicklinr@mcd.alcatel.be Thu Aug 19 09:21:00 1999 From: hicklinr@mcd.alcatel.be (Richard) Date: Thu, 19 Aug 1999 09:21:00 -0000 Subject: Imake and DLLs under Cygwin References: Message-ID: <37BC2F3E.36A01DA0@mcd.alcatel.be> > Good luck. > But please do not assume that X-server is that code is functional. > It is under development, and if you are willing to help > to finish this project, your help will be appreciated. > > > You can look at X11-def.cpp as an example in xfree source tree. > > I'm downloading now ... So with imake the 'foo-def.cpp' for libfoo.dll is just the 'foo.def' but with 'LIBRARY_VERSION' so that the imake rule can parameterise that through the preprocessor - in case anyone else has the same problem. I'm going on holiday now - where? The USA! PS re. X-server help: I'm certainly not a Windows device driver expert so I suspect my effectiveness would not be high ... From Ssiddiqi@InspirePharm.Com Thu Aug 19 09:31:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 09:31:00 -0000 Subject: Imake and DLLs under Cygwin References: <37BC2F3E.36A01DA0@mcd.alcatel.be> Message-ID: > > Good luck. > > But please do not assume that X-server is that code is functional. > > It is under development, and if you are willing to help > > to finish this project, your help will be appreciated. > > > > You can look at X11-def.cpp as an example in xfree source tree. > > > I'm downloading now ... > > So with imake the 'foo-def.cpp' for libfoo.dll is just the 'foo.def' but > with 'LIBRARY_VERSION' so that the imake rule can parameterise > that through > the preprocessor - in case anyone else has the same problem. > Why can you not make the foo-def.cpp on Sun? You wrote you had your software working on Sun? Am I right? You can use nm and sed on libs you compiled on Sun to make your fpp-def.cpp then ftp over to Win32 and compile. That is what I do if I had a software already compiled on a Unices platform. > I'm going on holiday now - where? The USA! oh? where,east, south, west, north, mideast, southeast, northeast... unfortunately USA is too big to figure out where you would be in USA ;-) > > PS re. X-server help: I'm certainly not a Windows device driver > expert so I > suspect my effectiveness would not be high ... > N/P. For Cygwin users: today a conversation at Xfree86 developers list started a thread on Cygw-xfree. Literally over 100 messages came within an hour and some (at least couple) from a commercial setup of Cygwin like product were suggesting that Cygwin would never work. The only way to go is use MSVC and their products, plus rewrite 99% of the Xfree86 code with Win32 API!!! huh? From hicklinr@mcd.alcatel.be Thu Aug 19 09:40:00 1999 From: hicklinr@mcd.alcatel.be (Richard) Date: Thu, 19 Aug 1999 09:40:00 -0000 Subject: Imake and DLLs under Cygwin References: Message-ID: <37BC33AD.91CFF26@mcd.alcatel.be> > > So with imake the 'foo-def.cpp' for libfoo.dll is just the 'foo.def' but > > with 'LIBRARY_VERSION' so that the imake rule can parameterise > > that through > > the preprocessor - in case anyone else has the same problem. > Why can you not make the foo-def.cpp on Sun? You wrote you had > your software working on Sun? Am I right? You can use nm and sed on libs you > compiled on Sun to make > your fpp-def.cpp then ftp over to Win32 and compile. The imake rules on Solaris don't produce make rules that require a .def file since the mechanism to produce shared libraries is different on Solaris. This wasn't a problem with the Solaris build. > > I'm going on holiday now - where? The USA! > oh? where,east, south, west, north, mideast, southeast, northeast... > unfortunately USA is too big to figure out where you would be in USA ;-) East, west, and middle (DC, SF and the Rockies). > N/P. For Cygwin users: today a conversation at Xfree86 developers list > started a thread on Cygw-xfree. Literally over 100 messages came within an > hour and some (at least couple) from a commercial setup of Cygwin like > product were suggesting that Cygwin would never work. The only way to go is > use MSVC and their products, plus rewrite 99% of the Xfree86 code with Win32 > API!!! huh? What reasons did they give? From Ssiddiqi@InspirePharm.Com Thu Aug 19 09:45:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 09:45:00 -0000 Subject: Imake and DLLs under Cygwin References: <37BC33AD.91CFF26@mcd.alcatel.be> Message-ID: > The imake rules on Solaris don't produce make rules that require > a .def file > since the mechanism to produce shared libraries is different on > Solaris. This > wasn't a problem with the Solaris build. You did not understand my point. use nm and sed to make *.def file using nm and sed of your lib*.a or lib*.so whatever. > > > > I'm going on holiday now - where? The USA! > > oh? where,east, south, west, north, mideast, southeast, northeast... > > unfortunately USA is too big to figure out where you would be in USA ;-) > > East, west, and middle (DC, SF and the Rockies). Have fun. Just do not go to Southeast DC, unless you want to get robbed of every pennies you would have. I lived in DC area thus this is the only thing I would suggest. > > > N/P. For Cygwin users: today a conversation at Xfree86 developers list > > started a thread on Cygw-xfree. Literally over 100 messages > came within an > > hour and some (at least couple) from a commercial setup of Cygwin like > > product were suggesting that Cygwin would never work. The only > way to go is > > use MSVC and their products, plus rewrite 99% of the Xfree86 > code with Win32 > > API!!! huh? > > What reasons did they give? Reasons? Very simple... so the would be X-sever would get hooked to their products. They did not give these reasons in writing but that is what I would conclude. > From Ssiddiqi@InspirePharm.Com Thu Aug 19 09:53:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 09:53:00 -0000 Subject: Win32 version of XFree86 References: <199908191628.MAA22737@inspire.InspirePharm.Com> Message-ID: Hi, Thanks for your message. > I noticed your discussion on the XFree86 developer list about an Open > Source version of X11 that runs on Win32. Myself and another > developer have started looking into this, and it would be useful if > we could all cooperate on this. Definitely cooperation would be highly appreciated. I am too far now :-) Finished looking at the code almost several months ago. I am down to the point where only devices drivers issues needs to be solved either by using NT DKK or DirectX, then X would be up and running. We are not talking of a bit hacky strip down port. Hopefully it would be a 100% Xfree86 port to Win32. I used Cygwin B20.1/also recent snapshots, and GCC 2.95. In addition to Xfree86 developers list, I would suggest could you please join us at cygwin-xfree@sourceware.cygnus.com. The X11R6.3, X11R6.4 is available from my webpages at http;//siddiqi.webjump.com. The Xfree86 patches against Xfree86 3.3.x as well as binaries with non-functional server are available at ftp;//sourceware.cygnus.com/pub/cygwin/xfree >It looks like you have done a lot of > work already to get XFree86 to build for Win32. Have you done work > for X11R6.4 standard code, or just the XFree86 code base? All, x11r6.3, x11r6.4 and xfree86 3.3.4 (except the devices drivers code that where i need all the help anyone could offer) > > In any case, I am definately interested in your patches for this, > either for raw X11R6.4 sources or for XFree86 3.3.x sources. Please > let me know where I can get your patches from so I can play around > with it. > > Also I am interested to hear more about your ideas for getting the X- > server running in a windowed environment (ie: X apps seamlessly > runinng on the Win32 desktop). X-apps ( clinets) from x11r6.x and xfree86 3.3.4 works without problem, though a commercial x is required till we figure out devices drivers code and have xfree86 servers up and runing. Regards Suhaib PS: I am cc'ing to our cygwin-xfree mailing list for other users info. I hope it is Ok with you. > > Regards, > > > +---------------------------------------------------------------+ > | SciTech Software - Building Truly Plug'n'Play Software! | > +---------------------------------------------------------------+ > | Kendall Bennett | Email: KendallB@scitechsoft.com | > | Director of Engineering | Phone: (530) 894 8400 | > | SciTech Software, Inc. | Fax : (530) 894 9069 | > | 505 Wall Street | ftp : ftp.scitechsoft.com | > | Chico, CA 95928, USA | www : http://www.scitechsoft.com | > +---------------------------------------------------------------+ > From hicklinr@mcd.alcatel.be Thu Aug 19 10:00:00 1999 From: hicklinr@mcd.alcatel.be (Richard) Date: Thu, 19 Aug 1999 10:00:00 -0000 Subject: Imake and DLLs under Cygwin References: Message-ID: <37BC3882.90E62F98@mcd.alcatel.be> > > The imake rules on Solaris don't produce make rules that require > > a .def file > > since the mechanism to produce shared libraries is different on > > Solaris. This > > wasn't a problem with the Solaris build. > You did not understand my point. > use nm and sed to make *.def file using nm and sed of your lib*.a or lib*.so > whatever. Okay: that's what I did in effect. The lib*.a built correctly, but then make stopped, telling me there was no rule to make *-def.cpp. I want to hand the product to people who will develop it on Solaris and hope that it will then rebuild under Cygwin without a problem. I didn't know what a *-def.cpp was, so I just made a *.def and considered rewriting the imake rule so that it skipped the *-def.cpp bit. But I'd rather not mess with it in case I regret it later. Now it's okay - just a *-def.cpp is just a *.def with LIBRARY_VERSION in it where cpp (through a imake rule called SharedLibraryTarget) can stick the version number. I made up the file with 'nm' and then manually. > Have fun. Just do not go to Southeast DC, unless you want to get robbed of > every pennies you would have. I lived in DC area thus this is the only > thing I would suggest. Advice accepted! From Ssiddiqi@InspirePharm.Com Thu Aug 19 10:07:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 10:07:00 -0000 Subject: Imake and DLLs under Cygwin References: <37BC3882.90E62F98@mcd.alcatel.be> Message-ID: *> > Okay: that's what I did in effect. The lib*.a built correctly, > but then make > stopped, telling me there was no rule to make *-def.cpp. I want > to hand the > product to people who will develop it on Solaris and hope that it > will then > rebuild under Cygwin without a problem. I didn't know what a > *-def.cpp was, so > I just made a *.def and considered rewriting the imake rule so > that it skipped > the *-def.cpp bit. But I'd rather not mess with it in case I > regret it later. > Now it's okay - just a *-def.cpp is just a *.def with > LIBRARY_VERSION in it > where cpp (through a imake rule called SharedLibraryTarget) can stick the > version number. I made up the file with 'nm' and then manually. That is how I make *-def.cpp files... make them on Unices using Unices libs then ftp them to Win32 and compile code. > > > Have fun. Just do not go to Southeast DC, unless you want to > get robbed of > > every pennies you would have. I lived in DC area thus this is the only > > thing I would suggest. > > Advice accepted! > > From Ssiddiqi@InspirePharm.Com Thu Aug 19 11:10:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 11:10:00 -0000 Subject: FW: drivers Message-ID: following message just came from a friend who has started now working on devices drivers for cygwin-xfree. it might of interest to others, so they know what is being done. Suhaib > -----Original Message----- > From: Anton van Straaten [ mailto:anton@appsolutions.com ] > Sent: Thursday, August 19, 1999 12:47 PM > To: Suhaib Siddiqi > Subject: RE: drivers > > > Suhaib, > > The OS-specific code was a big help - I took a look at it this morning. > > Question: I assume it's OK if I rewrite the internals of functions like > xf86ReadBIOS (in cygwin_mmap.c), to use NT API calls (e.g. calls to > DeviceIOControl)? Since this code is going to be very platform-specific > anyway, I'm thinking there's not much point in trying to use Unix-style > functions like device_open to access NT drivers. > > It looks to me as though the direct memory access will be fairly > straightforward, using the DDK sample driver as you suggested (with > modifications if necessary). I haven't looked at the port access > functions > yet, but I'm hoping the situation is similar. > > I looked at the idea of using DirectX. For the memory access, I > don't think > it will make things any easier, in fact it will probably be more > complicated. DirectX may help more with port access, and it may eliminate > the need for another custom driver, so I'll keep that in mind. > > How much work is going to be involved when I get to the point of > wanting to > test this? Will I need to build the entire system from the full source > tree? Or am I just going to send the code to you for testing? > > > Your help is highly appreciated. > > You're welcome. I couldn't have gotten OpenDX running without > the work you > did with it and Cygwin, so I'm happy if I can return the favor. Also, I > quite like the idea of a free X Server for NT (call me perverse!) > > Regards, > Anton > > > > -----Original Message----- > > From: Suhaib Siddiqi [ mailto:Ssiddiqi@InspirePharm.Com ] > > Sent: Wednesday, August 18, 1999 7:29 AM > > To: Anton van Straaten > > Subject: RE: drivers > > > > > > > > > > Hi Anton, > > Thanks for your help. It is very much appreciated. > > > > > I think that's a good idea, thanks. If it's not a lot of > > > trouble, go ahead > > > and send this to me. > > > > The different OS specific code is attached. I Tar gzipped it > because some > > of the subdirectories contains symlinks to the code in > os-support/shared. > > WinZip seems to mess-up the symbolic links. > > > > > > > > I took a brief look at the OS/2 driver code, as well as the sample NT > > > drivers. The sample NT drivers look fairly familiar to me, > > > because a lot of > > > the DDK calls are roughly equivalent to the higher-level Win32 API. > > > > I think rewriting OS/2 drivers will be a lot of work, as you mentioned. > > There is also no guarantee that ported OS/2 driver will work on > WinNT. As > > far as I know the OS/2 drivers from Holger Veit can violate NT hardware > > protection mode. Therefore I thought using NT DDK samples, or something > > like that would be a better idea. All what is needed; is > mapping physical > > memory and IOports to user area. I think it can be either done > > using NT DDK > > or > > DirectX. According to Microsoft Knowledge Base Direct X allows direct > > accessing to hardware-abstraction layer, reading and mapping BIOS and > > physical memory of Video Drivers. I am quoting this from MSDN > > web pages, I > > have zero knowledge on how to write code for devices using DDK > or DirectX. > > > > > But I > > > think there could be quite a bit of work in getting it all to > > > work together > > > with xfree86. Looking at the xfree86 calling code is > > definitely the next > > > step, and I could well imagine that some shortcuts might be > > > possible at that > > > level. > > > > I assume too, some shortcuts are possible. Therefore I asked > your help. > > In the os-support.tar.gz please ignore the subdirectory > "cygwin." It has > > some nonsense code in it. I added it intentionally when > patching XFree86 > > source tree so I can compile rest of the XFree86 source tree. > > > > > > > > If I want to download the full XFree86 source tree, where should > > > I get that > > > from? > > > > The full Xfree86 source tree is 100 MB. I think what is needed > > is different > > OS-support examples. However, if you need the full source tree, > > I can give > > you access. At the moment the source tree is at XFree86 > Developers site, > > which is not accessible to non-members. > > > > Please make sure you add your copyright notice at the top of > each sources > > file, you write. I suggest this because the your code will > eventually get > > merged with XFree86 version 4.x. > > > > > > > > I'm still busy catching up on some other work, but I'll be > able to spend > > > more time on this in the next few days. > > > > > > > Your help is highly appreciated. > > > > Regards > > Suhaib > > > > > > > Anton > > > > > > From Ssiddiqi@InspirePharm.Com Thu Aug 19 12:12:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 12:12:00 -0000 Subject: drivers - again, i.e. DirectX <-> DGA References: Message-ID: > Subject: drivers - again, i.e. DirectX <-> DGA > > > On Thu, 19 Aug 1999, Suhaib Siddiqi wrote: > > ..... > > > Question: I assume it's OK if I rewrite the internals of > functions like > > > xf86ReadBIOS (in cygwin_mmap.c), to use NT API calls (e.g. calls to > > > DeviceIOControl)? Since this code is going to be very > platform-specific > > > anyway, I'm thinking there's not much point in trying to use > Unix-style > > > functions like device_open to access NT drivers. > > In fact. Even the OS/2 implementation is, in my opinion, unusable except > as a hint on what is needed (i.e., a direct port would be intrinsically > whizmical). Agreed!!! The Win32 API lacks the equivalent of many DOS32 stuff. You cannot take Os/2 code and simply recompile it on Win32. One commercial vendor (www.codefx.com) claims their tools can do that. I sent them code from Holger Veit as a test case. They failed and since then they have stopped e-mailing me to license their Os/2 to Win32 API auto-conversion tools. > - DirectX 5+ is available for all the Win32 platforms (except for Win32s > and CE, which are not relevant in our context); this means, among other No that is not quite correct. DirectX 5.0 does not work on Nt. The only thing wich work on Nt 4.0 is DirectX 3.0, i.e. also with Service Pak 4.0 or 3.0. Direct 3 does not work on Win2K > things, you may avoid using separate XFree86 drivers for Windows 95, > Windows 98, NT 4.0 and NT 5.0/Win2k (since their video subsystems > are non-trivially different; just think of the PnP or multi-monitor > support). We are aiming for it, but there are pitfalls. DDK does not fully support Win 9x and DirectX higher then 3.0 does not work on Nt 4.0. These are the Micro$oft gimmiks to sell more different versions of OS and force the developers to maintain several versions of their sofwtare for different version of Windows. > - DirectX apps may be installed and used by non-administrator users (and > can't nuke the whole system down to its knees, which is especially > important for many people). > - As I told you before, I would not be surprised if DGA could be directly > mapped on top of DirectX. > > I have not used DirectX (a friend of mine did, and yelled for some > months), but I read its documentation thoroughly and I know it can be > done - VMware itself is a proof in concept, though its goals were pretty > different. VMware can be a proof in concept but I was not very impressed. First VMWare work on NT only. Second it supports DX 3.0 on Nt 4.0 because any higher version of DX on NT 4.0 will pop-up a box with DLL initialization errors. > > Please send me details of the DGA thing (I think it might be interesting > having both 3.3.x and the preliminary 4.0 specs) > What is DGA? anyway :-) Do I already have something like that in my Xfree code? Regards Suhaib > Best regards > > 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! > =================================================== > From KendallB@scitechsoft.com Thu Aug 19 12:16:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Thu, 19 Aug 1999 12:16:00 -0000 Subject: Win32 version of XFree86 References: <199908191628.MAA22737@inspire.InspirePharm.Com> Message-ID: <10780.935090194.0@NO-ID-FOUND.mhonarc.org> Hi Suhaib, > > I noticed your discussion on the XFree86 developer list about an Open > > Source version of X11 that runs on Win32. Myself and another > > developer have started looking into this, and it would be useful if > > we could all cooperate on this. > > Definitely cooperation would be highly appreciated. I am too far > now :-) Finished looking at the code almost several months ago. I > am down to the point where only devices drivers issues needs to be > solved either by using NT DKK or DirectX, then X would be up and > running. We are not talking of a bit hacky strip down port. > Hopefully it would be a 100% Xfree86 port to Win32. I used Cygwin > B20.1/also recent snapshots, and GCC 2.95. Sounds great! I know that Rich Thomson (CC'ed on this email) has been looking into this and the work you have done will be a great start to this project for both of us. We are planning on doing the server that lives on top of DirectX. Rich knows lots about X11 server development, but little about DirectX (although he has been reading heavily ;-). I know little about X11 server development (other than writing chipset drivers in XFree86 which I have done), but lots about DirectX. Sounds like you have the stuff to make the build process work nicely! > In addition to Xfree86 developers list, I would suggest could you > please join us at cygwin-xfree@sourceware.cygnus.com. Sure. How do I join this mailing list?? > The X11R6.3, X11R6.4 is available from my webpages at > http;//siddiqi.webjump.com. > The Xfree86 patches against Xfree86 3.3.x as well as binaries with > non-functional server are available at > ftp;//sourceware.cygnus.com/pub/cygwin/xfree Great, I will go download them now. > >It looks like you have done a lot of > > work already to get XFree86 to build for Win32. Have you done work > > for X11R6.4 standard code, or just the XFree86 code base? > > All, x11r6.3, x11r6.4 and xfree86 3.3.4 (except the devices > drivers code that where i need all the help anyone could offer) Cool! So you have patched sources for raw X11R6.4? I know that is what Rich was starting to work on, although we want to build it all with Microsoft Visual C++ and Borland C++ instead of Gygwin. Have you done any work to get these compilers to work at all? > PS: I am cc'ing to our cygwin-xfree mailing list for other users > info. I hope it is Ok with you. Sure. Regards, +---------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +---------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +---------------------------------------------------------------+ From Ssiddiqi@InspirePharm.Com Thu Aug 19 12:42:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 12:42:00 -0000 Subject: Win32 version of XFree86 References: <199908191921.PAA24244@inspire.InspirePharm.Com> Message-ID: > Sounds great! I know that Rich Thomson (CC'ed on this email) has been > looking into this and the work you have done will be a great start to > this project for both of us. We are planning on doing the server that > lives on top of DirectX. Rich knows lots about X11 server > development, but little about DirectX (although he has been reading > heavily ;-). I know little about X11 server development (other than > writing chipset drivers in XFree86 which I have done), but lots about > DirectX. Sounds like you have the stuff to make the build process > work nicely! Well then you could just write a devices driver and some code which uses this driver. The code goes into Xserver/hw/xfree86/win32 and that would BE IT!!!. There is really no need for you guys to restart the stuff from scratch. I had works on the code for several months spending several hours a day and if you trust it is in quite good shap for Cygwin/Win32 platform. > > > In addition to Xfree86 developers list, I would suggest could you > > please join us at cygwin-xfree@sourceware.cygnus.com. > > Sure. How do I join this mailing list?? > > > The X11R6.3, X11R6.4 is available from my webpages at > > http;//siddiqi.webjump.com. > > The Xfree86 patches against Xfree86 3.3.x as well as binaries with > > non-functional server are available at > > ftp;//sourceware.cygnus.com/pub/cygwin/xfree > > Great, I will go download them now. sned mail to subscribe-cygwin-xfree@sourceware.cygnus.com > > > >It looks like you have done a lot of > > > work already to get XFree86 to build for Win32. Have you done work > > > for X11R6.4 standard code, or just the XFree86 code base? > > > > All, x11r6.3, x11r6.4 and xfree86 3.3.4 (except the devices > > drivers code that where i need all the help anyone could offer) > > Cool! So you have patched sources for raw X11R6.4? I know that is > what Rich was starting to work on, although we want to build it all > with Microsoft Visual C++ and Borland C++ instead of Gygwin. Have you > done any work to get these compilers to work at all? If you intend to spend a year re-writing code and assembly code (total 30 MB) in Xserver and its subdirectories, you are welcome to try MSVC or Borland. The Win32 code in X11R6.x source tree, for libs only, is for MSVC 4.0 and it cannot be compiled even with MSVC 5.0 or 6.0. You would be undertaking a mega project which you may not be able to finish. MASMS cannot deal with assembly code for various graphics cards in Xserver/hw/xfree86 and its subdirectories. It will return i386 syntex error for literally every line of the assembly code. I gave it a shot and i would prefer to keep my hands off from MSVC. I am not a programmer who could write 10s of MB of assembly code in Micro$oft impossed language. Regards Suhaib > > > PS: I am cc'ing to our cygwin-xfree mailing list for other users > > info. I hope it is Ok with you. > > Sure. > > Regards, > > > +---------------------------------------------------------------+ > | SciTech Software - Building Truly Plug'n'Play Software! | > +---------------------------------------------------------------+ > | Kendall Bennett | Email: KendallB@scitechsoft.com | > | Director of Engineering | Phone: (530) 894 8400 | > | SciTech Software, Inc. | Fax : (530) 894 9069 | > | 505 Wall Street | ftp : ftp.scitechsoft.com | > | Chico, CA 95928, USA | www : http://www.scitechsoft.com | > +---------------------------------------------------------------+ > From KendallB@scitechsoft.com Thu Aug 19 12:53:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Thu, 19 Aug 1999 12:53:00 -0000 Subject: Win32 version of XFree86 References: <199908191921.PAA24244@inspire.InspirePharm.Com> Message-ID: <18902.935092437.0@NO-ID-FOUND.mhonarc.org> Hi Suhaib, > Well then you could just write a devices driver and some code > which uses this driver. The code goes into > Xserver/hw/xfree86/win32 and that would BE IT!!!. That sounds really cool. All we need to do then is build a chipset driver that runs on top of DirectX. I am very familiar with DirectX, so I can probably whip that up quickly. What about event handling stuff? Has that already been implemented (using DirectInput or some other mechanism)? > There is really no need for you guys to restart the stuff from > scratch. I had works on the code for several months spending > several hours a day and if you trust it is in quite good shap for > Cygwin/Win32 platform. I have no intention of starting from scratch if you have already done all the ground work. I am sure that Rich feels the same way also ;-) > > Cool! So you have patched sources for raw X11R6.4? I know that is > > what Rich was starting to work on, although we want to build it all > > with Microsoft Visual C++ and Borland C++ instead of Gygwin. Have you > > done any work to get these compilers to work at all? > > If you intend to spend a year re-writing code and assembly code > (total 30 MB) in Xserver and its subdirectories, you are welcome to > try MSVC or Borland. I thought the X11R6.4 source tree was C code only since it can compile for non-intel CPU's? What assembler code is present in the code, and is it localised at all? More specifically if the assembler code is just in chipset drivers, we can throw those away since we don't need that (DirectX becomes the chipset driver). > The Win32 code in X11R6.x source tree, for libs only, is for MSVC > 4.0 and it cannot be compiled even with MSVC 5.0 or 6.0. You would > be undertaking a mega project which you may not be able to finish. Certainly getting it all working with GCC first is a more desireable option then, but I would like to be able to build with MSVC and other Win32 compilers because they produce much better code than GCC does (although 2.9.5 may be better now). > MASMS cannot deal with assembly code for various graphics cards in > Xserver/hw/xfree86 and its subdirectories. It will return i386 > syntex error for literally every line of the assembly code. Sure, but we don't need *any* of that code to be compiled for the Win32 version, since we don't be doing any chipset specific code. All the code to talk to the hardware will be going via DirectX. > I gave it a shot and i would prefer to keep my hands off from MSVC. > I am not a programmer who could write 10s of MB of assembly code > in Micro$oft impossed language. Actually the assembler code in XFree86 is supposed to be portable to non-GCC compilers, but perhaps it isn't. I thought there was some kind of assyntax.h header file that would allow the code to be converted into MASM assembler code. But like I said, we can probably remove 95% of the assembler code problems since a lot of it may just be in the chipset drivers. Unless of course gobs of it are in the cfb code? Regards, +---------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +---------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +---------------------------------------------------------------+ From Ssiddiqi@InspirePharm.Com Thu Aug 19 13:15:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 13:15:00 -0000 Subject: Win32 version of XFree86 References: <199908191959.PAA24634@inspire.InspirePharm.Com> Message-ID: > That sounds really cool. All we need to do then is build a chipset > driver that runs on top of DirectX. I am very familiar with DirectX, > so I can probably whip that up quickly. Could you first look into various OS-specific codes in the Xserver/hw/xfree86/os-support? That is where most of the work we need to do. That is provide those functionalities for Win32 API. > I thought the X11R6.4 source tree was C code only since it can > compile for non-intel CPU's? What assembler code is present in the > code, and is it localised at all? More specifically if the assembler > code is just in chipset drivers, we can throw those away since we > don't need that (DirectX becomes the chipset driver). X11R6.4 is, but not the Xfree86 which is being added by Xfree86 Org. > Sure, but we don't need *any* of that code to be compiled for the > Win32 version, since we don't be doing any chipset specific code. All > the code to talk to the hardware will be going via DirectX. I think for you would be best to start putting directX support in Xserver/hw/xfree86/os-support by adding your code to a sub-directory called win32. Then for there we start and see waht would need further fix or would need to be unnecessary. > Actually the assembler code in XFree86 is supposed to be portable to > non-GCC compilers, but perhaps it isn't. I thought there was some > kind of assyntax.h header file that would allow the code to be > converted into MASM assembler code. True, but Xfree86 best compiles with GCC and it is known since long time. Some of the commercial compilers on Linux cannot even handle some of the dirty X headers... on Win32 MSVC, simply hates the X headers, unless you pay to Hummingbird and buy their Xceed XDK but then you cannot redistribute your X code without paying $$ to Hummingbird first. > > But like I said, we can probably remove 95% of the assembler code > problems since a lot of it may just be in the chipset drivers. Unless > of course gobs of it are in the cfb code? cfb, mfb and dix etc is not a problem. That is pure C code and compiles perfect with GCC. As far as your comments on GCC 2.95 performance are concerned I think GCC 2.95 can do a better job when porting a UNIX code then commercial compilers. However Mumit Khan is the GCC Win32 expert and would be a right person to address you comments. Regards Suhaib > > Regards, > > > +---------------------------------------------------------------+ > | SciTech Software - Building Truly Plug'n'Play Software! | > +---------------------------------------------------------------+ > | Kendall Bennett | Email: KendallB@scitechsoft.com | > | Director of Engineering | Phone: (530) 894 8400 | > | SciTech Software, Inc. | Fax : (530) 894 9069 | > | 505 Wall Street | ftp : ftp.scitechsoft.com | > | Chico, CA 95928, USA | www : http://www.scitechsoft.com | > +---------------------------------------------------------------+ > From Ssiddiqi@InspirePharm.Com Thu Aug 19 13:35:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Thu, 19 Aug 1999 13:35:00 -0000 Subject: Win32 version of XFree86 References: <199908191959.PAA24634@inspire.InspirePharm.Com> Message-ID: By the way, after you download *&.diff files do not look into os-support/cygwin code. that is a nonsense at this point. I added it intentionally to see how much from xfree86 would compile and what should be patched... then worry the rest later. Suhaib From KendallB@scitechsoft.com Thu Aug 19 15:58:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Thu, 19 Aug 1999 15:58:00 -0000 Subject: Win32 version of XFree86 References: <199908191959.PAA24634@inspire.InspirePharm.Com> Message-ID: <29087.935103519.0@NO-ID-FOUND.mhonarc.org> "Suhaib Siddiqi" wrote: > > That sounds really cool. All we need to do then is build a chipset > > driver that runs on top of DirectX. I am very familiar with DirectX, > > so I can probably whip that up quickly. > > Could you first look into various OS-specific codes in the > Xserver/hw/xfree86/os-support? That is where most of the work we > need to do. That is provide those functionalities for Win32 API. Ok. So it sounds like it is all compiling, but a lot of the framework code is not necessarily there? What about event handling? Is any of that done yet? > > I thought the X11R6.4 source tree was C code only since it can > > compile for non-intel CPU's? What assembler code is present in the > > code, and is it localised at all? More specifically if the assembler > > code is just in chipset drivers, we can throw those away since we > > don't need that (DirectX becomes the chipset driver). > > X11R6.4 is, but not the Xfree86 which is being added by Xfree86 Org. I have not checked specifically, but how much assembler code is there in XFree86 that is outside of chipset specific drivers? > > Sure, but we don't need *any* of that code to be compiled for the > > Win32 version, since we don't be doing any chipset specific code. All > > the code to talk to the hardware will be going via DirectX. > > I think for you would be best to start putting directX support in > Xserver/hw/xfree86/os-support by adding your code to a > sub-directory called win32. Then for there we start and see waht > would need further fix or would need to be unnecessary. Sure, but the actual DirectX rendering code would be done as a chipset driver within the SVGA driver framework. That is the quickest and easiest way to get something going (and what I am familiar with ;-). > > Actually the assembler code in XFree86 is supposed to be portable to > > non-GCC compilers, but perhaps it isn't. I thought there was some > > kind of assyntax.h header file that would allow the code to be > > converted into MASM assembler code. > > True, but Xfree86 best compiles with GCC and it is known since > long time. Some of the commercial compilers on Linux cannot even > handle some of the dirty X headers... on Win32 MSVC, simply hates > the X headers, unless you pay to Hummingbird and buy their Xceed > XDK but then you cannot redistribute your X code without paying $$ > to Hummingbird first. Well XFree86 also compiles and runs just fine on OS/2, but I am not sure what compiler they use. I was under the impression that either Watcom C++ or IBM VisualAge C++ was used to compile the OS/2 version, rather than a GNU C variant. However I may be wrong (since emx for OS/2 is the GCC for that OS). > > But like I said, we can probably remove 95% of the assembler code > > problems since a lot of it may just be in the chipset drivers. Unless > > of course gobs of it are in the cfb code? > > cfb, mfb and dix etc is not a problem. That is pure C code and compiles > perfect with GCC. Ok. So where does the bulk of the assembler code in XFree86 come from then? If it is not in the above, then it must really be just chipset driver specifics right? And we don't need those... > As far as your comments on GCC 2.95 performance are concerned I > think GCC 2.95 can do a better job when porting a UNIX code then > commercial compilers. However Mumit Khan is the GCC Win32 expert > and would be a right person to address you comments. Sure, but even GCC 2.9.5 does not compare to the latest commercial compilers from Microsoft, Intel and MetroWerks. Regards, +---------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +---------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +---------------------------------------------------------------+ From ssiddiqi@inspirepharm.com Thu Aug 19 17:32:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Thu, 19 Aug 1999 17:32:00 -0000 Subject: Win32 version of XFree86 References: <199908192303.TAA27199@inspire.InspirePharm.Com> Message-ID: > > Could you first look into various OS-specific codes in the > > Xserver/hw/xfree86/os-support? That is where most of the work we > > need to do. That is provide those functionalities for Win32 API. > > Ok. So it sounds like it is all compiling, but a lot of the framework > code is not necessarily there? What about event handling? Is any of > that done yet? > That code compiles too from XFree86. Most of stuff for event handeling in xfree86 is supported by Cygwin UNIX emulation layer. > > X11R6.4 is, but not the Xfree86 which is being added by Xfree86 Org. > > I have not checked specifically, but how much assembler code is there > in XFree86 that is outside of chipset specific drivers? It is in various sub-directories in Xserver/hw/xfree86. The VGA/SVGA chipset code you want to hook to DirectX has a lot of assembly code in it. Look at Xserver/hw/xfree86/vga's directories. > Sure, but the actual DirectX rendering code would be done as a > chipset driver within the SVGA driver framework. That is the quickest > and easiest way to get something going (and what I am familiar with > ;-). If you add your code into hw/xfree86/os-support/win32 it would use the SVGA chipset code from hw/xfree86/svga2, and hw/xfree86/svga256 etc. Your could should compile as a static library which could be linked to X-server excutables. > Well XFree86 also compiles and runs just fine on OS/2, but I am not > sure what compiler they use. I was under the impression that either > Watcom C++ or IBM VisualAge C++ was used to compile the OS/2 version, > rather than a GNU C variant. However I may be wrong (since emx for > OS/2 is the GCC for that OS). They used EMX, that is GCC 2.8.1 and GNU gas assembler. Xfree86/Os2 port is a model for porting Xfree86 to Win32. Holger wrote his own devices drivers which allow direct access to i/o ports and maping physical memory to user area, because OS/2 DDK does not offer these features. For Win32 we could take DDK or DirectX to access i/o and map, unmap physical memory to user area??? > > cfb, mfb and dix etc is not a problem. That is pure C code and compiles > > perfect with GCC. > > Ok. So where does the bulk of the assembler code in XFree86 come from > then? If it is not in the above, then it must really be just chipset > driver specifics right? And we don't need those... It is almost in every subdirectory inside Xserver/hw/xfree86/. I prefer doing a direct port of Xfree86 to Win32, as Holger did for OS/2. Throwing away the hw/xfree86 means the X-server would not be an Xfree86 port, rather X11R6.x classical X. > Sure, but even GCC 2.9.5 does not compare to the latest commercial > compilers from Microsoft, Intel and MetroWerks. I disagree, particularly with MSVC. MSVC is very buggy. After M$ released MSVC 6.0, a month after they released a major services pack 1.0 to address some serious bugs. Since then 3 service packs had been released and 4th one is on its way. For porting Unices C codes I had better experience with GCC and EGCS. I had some C sources which compiled with Absoft Pro without problems, and MSVC gave a heck of the problems of fixing the code so MSVC can compile it. MSVC does do a good optimization job. Suhaib > > Regards, > > > +---------------------------------------------------------------+ > | SciTech Software - Building Truly Plug'n'Play Software! | > +---------------------------------------------------------------+ > | Kendall Bennett | Email: KendallB@scitechsoft.com | > | Director of Engineering | Phone: (530) 894 8400 | > | SciTech Software, Inc. | Fax : (530) 894 9069 | > | 505 Wall Street | ftp : ftp.scitechsoft.com | > | Chico, CA 95928, USA | www : http://www.scitechsoft.com | > +---------------------------------------------------------------+ > From cgf@cygnus.com Sat Aug 21 19:18:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Sat, 21 Aug 1999 19:18:00 -0000 Subject: Win32 version of XFree86 References: <199908191921.PAA24244@inspire.InspirePharm.Com> <199908191954.MAA01296@cygnus.com> Message-ID: <19990821222034.A1149@cygnus.com> On Thu, Aug 19, 1999 at 12:52:32PM -0800, Kendall Bennett wrote: >Certainly getting it all working with GCC first is a more desireable >option then, but I would like to be able to build with MSVC and other >Win32 compilers because they produce much better code than GCC does >(although 2.9.5 may be better now). I think that recent benchmarks have shown that gcc is at least approaching MSVC speeds in most regards and surpassing it in a few areas. I'm not a gcc engineer, however, and I can't give you complete details. I can say that the PII optimizations in our Code Fusion product are rumored to make linux run as much as 5% faster. That said, however, it may not be too hard to get things compiled with MSVC. I would think that the major problems would be environment related, i.e., how do you handle things like ptys, paths, etc. -chris From khan@xraylith.wisc.EDU Sat Aug 21 23:53:00 1999 From: khan@xraylith.wisc.EDU (Mumit Khan) Date: Sat, 21 Aug 1999 23:53:00 -0000 Subject: Win32 version of XFree86 References: <19990821222034.A1149@cygnus.com> Message-ID: <199908220653.BAA06261@mercury.xraylith.wisc.edu> Chris Faylor writes: > > I think that recent benchmarks have shown that gcc is at least > approaching MSVC speeds in most regards and surpassing it in a > few areas. In one area however, gcc trails behind the aforementioned compilers quite badly -- floating point. My code, which is numerically intensive, shows about 15-35% degradation using gcc. For integer code, it's still 5-20% slower than MSVC 6.x. One big problem is the way x86 machine description is written in GCC, and that's the primary bottleneck. For good news, see below. > I'm not a gcc engineer, however, and I can't give you complete details. > I can say that the PII optimizations in our Code Fusion product are > rumored to make linux run as much as 5% faster. Yes. Cygnus has donated the new ia32 backend and my numerical code shows as good a performance as any of the commercial offerings. However, it'll be a while before this is integrated into FSF gcc (gcc-3.0 perhaps). Intel is not a good comparison; it's built for benchmarking, and chock full of bugs. MW5 is excellent for both C and C++. MSVC C is excellent, but C++ is quite behind when it comes to standard conformance (I can't use it on even the simplest C++ code making heavy use of templates for example). This is a topic for gcc lists, not xfree, so I'll rest here. Regards, Mumit From ssiddiqi@inspirepharm.com Sun Aug 22 08:02:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 22 Aug 1999 08:02:00 -0000 Subject: Win32 version of XFree86 References: <19990821222034.A1149@cygnus.com> Message-ID: > I think that recent benchmarks have shown that gcc is at least > approaching MSVC speeds in most regards and surpassing it in a > few areas. > > I'm not a gcc engineer, however, and I can't give you complete details. > I can say that the PII optimizations in our Code Fusion product are > rumored to make linux run as much as 5% faster. > > That said, however, it may not be too hard to get things compiled with > MSVC. I would think that the major problems would be environment > related, i.e., how do you handle things like ptys, paths, etc. > I did try MSVC, the proof is X11R6.4 and lessTif for Win32 (not Cygwin) on my URL. http://siddiqi.webjump.com . As far as I know programmers had played with Xfree86 code with MSVC and gave up after realizing the amount of work needs to be done. The Win32 support in X11R6.x libraries is not enough. It is out-dated. It compiles with MSVC 4.0 and older versions. It would require a major rewrite of Xfree86 code and as I said I would not have enough time for this mega project. > -chris > From rich.thomson@xmission.com Sun Aug 22 10:05:00 1999 From: rich.thomson@xmission.com (Rich Thomson) Date: Sun, 22 Aug 1999 10:05:00 -0000 Subject: Win32 version of XFree86 References: <19990821222034.A1149@cygnus.com> Message-ID: <199908221704.LAA26562@xmission.xmission.com> Hi, There isn't any need to cc: me on messages regarding a port of Xfree86 to Windows. In fact, I've unsubscribed from all xfree86 mailing lists. My interest is in a DirectX based server, not a port of Xfree86. I just don't think a port of xfree86 is the best path to a DirectX X server. I think you will get a better server by starting with the X11R6.4 sample server code and starting with a very simple X server hw layer that just pushes spans to the DirectDraw code. The X server is already plenty portable enough on its own for things like the necessary O/S services. Everything in the core X server code is written very portably. You may need to adjust the imake environment to suit newer compiler switches and so-on, but you should not need to make any changes to the X server core code. The X library code has already been built on Win32, so some Win32 environment support is already present in X. I believe they punted on xterm because of its pty usage, but it is a special case. Perhaps you could get xterm compiled with gcc/cygwin. At any rate, I'm more interested in a server before xterm. The difficulty in a Win32 non-DirectX X server in the past has had to do with the way resources are shared under X and under Windows. The two are not very compatible when it comes to things like colormap management and focus management and so-on. Trying to make top-level X client windows look like Win32 app client windows is annoying and tedious. DirectX lets you do away with GDI and take over the screen, which is exactly what an X server wants to do when it starts. No hw-specific drivers are needed because you rely on DirectDraw to provide the device abstraction. The X sample server is coded to handle memory-mapped frame buffers quite efficiently all in software. From a basic working server you begin optimizing higher-level requests from there. That is the X server I'm interested in making. Since a DX-based server wouldn't need any of xfree86/hw code, all that code just goes away. But wait, you just threw out 90% of the xfree86 server effort. Is there any reason to keep the remaining 10%? The remaining 10% of code consists of startup/shutdown code, font code, input device code, and the OS layer code. All of this code in xfree86 is from a unix viewpoint, so it must be changed anyway for a Win32 DirectX based X server. The startup/shutdown code can't be used from xfree86 because device management is totally different under Windows. The X server only requires a few routines for supporting the basic keyboard and mouse events and a few more for extension devices (like a gamepad/joystick). We can use Windows event mechanism, or use DirectInput for device input. Either way, we can't use the xfree86 code. The font code is probably stock X server font code, which means it can't take advantage of Windows fonts. Eventually you'd like to be able to take advantage of Windows installed fonts for a DirectX based server, so you'd need to adjust the font code. The OS layer code is easy to supply for native Win32. For several of the functions, you can use the unix equivalent just fine on Win32 (things like opening files, opening socket connections, etc). So, in the end, you can't hardly use any of the xfree86 code in a very useful way for a native Win32 directX-based X server. The part of the code that you can reuse comes from the core sample server, not from xfree86. If you tried to use the xfree86 code, you have to deal with the way it wants to talk directly to all the different hardware out there. The core X server itself isn't coded this way, the xfree86 portions of it are. The xfree86 portions include assembly code, unix-oriented I/O code, unix-oriented device management code. For a DirectX server these are replaced with DirectDraw and Win32. So in the end I came to the conclusion that trying to port Xfree86 would be more work than just porting the core sample server itself. This is usually not the case, because normally you don't have a HW-independent abstraction beneath you when porting the X server. Usually you have to do what Xfree86 has done and support the different hardware directly. Its tedious, cumbersome and *lots* of code for the amount of hardware in the PC world today. But with a DirectX PC, MS and the hardware vendor have already provided the abstraction that takes away the complexity of the hardware. You are, of course, free to pursue your own direction. However, I am more interested in making the X server I've described in this message. -- Rich From ssiddiqi@inspirepharm.com Sun Aug 22 10:24:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 22 Aug 1999 10:24:00 -0000 Subject: Cygwin32 and GPL concerns References: <19990822152206.C5300@turtle.tat.physik.uni-tuebingen.de> Message-ID: It is getting sort of confusing. Xfree86 License Page reads "However, some other Open Source compatible licenses are considered too restrictive for XFree86 use. They include the GNU Public License and the Perl Artistic License. " The Xfree86 License refers to Open Source "These terms are consistent with the Open Source definition. Some portions of XFree86 may be based on similar licences, like, for example, the BSD-style license" Now the Open Source License (OSI) reads: 9. License Must Not Contaminate Other Software. (back) Distributors of open-source software have the right to make their own choices about their own software. Yes, the GPL is conformant with this requirement. GPLed libraries `contaminate' only software to which they will actively be linked at runtime, not software with which they are merely distributed. ^^^^Note it is saying GPL is conformant with this.^^^ We need in put from a BOD member. Cygwin does not forbid a user to use Cygwin Tool chain, downlaod the Xfree86 code and compile it yourself. Cygwin also does not forbid a Commercial License holder (just like Microsoft commercial License Holders) not to redistribute products without code. My understanding is it requires the freely available Cygwin GPL version user to have the source code available if he chooses to distribute binaries. Cygwin avialble from Net forbids closing the product. Which is also part of Open Source Agreement. 7.Distribution of License. (back) This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement. Cygwin, I believe, also allows the clause 5. of Open Source 5. No Discrimination Against Persons or Groups. (back) In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process. Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself. I am sort of confused here and needs some insight from XFree86 BOD. If the Xfree86 source code has Win32 calls which can be compiled using GCC under Cygwin Envirment by any users is a contradiction to XFree86? Microsoft products will put more restrictions if you follow their Software Agreements. You would not be allowed to include DDK and DX dlls because the person who gets them from you cannot redistribute them. The only way you can do is to have only source code avaiable which compiles with MSVC tools, so license holders can compile it themselves. But this can be done with any product including Cygwin, that is have patched sources available which the user who would have needed development tool chains can compile it. Suhaib > -----Original Message----- > From: owner-devel@XFree86.Org [ mailto:owner-devel@XFree86.Org]On Behalf > Of Harald Koenig > Sent: Sunday, August 22, 1999 9:22 AM > To: devel@XFree86.Org > Subject: Re: Cygwin32 and GPL concerns > > > On Aug 22, Lynn Winebarger wrote: > > > On Sat, 21 Aug 1999, Kendall Bennett wrote: > > > > > Actually the above is incorrect. If you link *any* code with pure GPL > > > code, then all the rest of the code must be under GPL as well. The > > > catch is that the X11 license specifically allows for commercial use > > > of XFree86 code, and hence it is not possible to include any GPL'ed > > > code in XFree86. > > > > > The X11 license allows for fairly arbitrary sublicensing. That > > includes the GPL. It is GPL compatible. If I (or anyone else) > wanted, I > > could distribute XFree86 in its entirety under the GPL. > > you still haven't got it: the XFree86 license allows me/everone to build > commercial/closed products for which I do _not_ release sources. > linking against GPL won't allow me to do so anymore. > > so for me these licenses are _not_ compatible because GPL tries > to restrict > some of the freedoms of the X license. that's not what I would > call `compatible' ! > > > Harald > -- > All SCSI disks will from now on ___ _____ > be required to send an email notice 0--,| /OOOOOOO\ > 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ > \ \/OOOOOOOOOOOOOOO\ > \ > OOOOOOOOOOOOOOOOO|// > Harald Koenig, \/\/\/\/\/\/\/\/\/ > Inst.f.Theoret.Astrophysik // / \\ \ > koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ > From ssiddiqi@inspirepharm.com Sun Aug 22 11:01:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 22 Aug 1999 11:01:00 -0000 Subject: Win32 version of XFree86 References: <199908221704.LAA26562@xmission.xmission.com> Message-ID: Your approach is fine with me, if you are willing to do the DirectX work??? I have sorted out most of the core X11R6.x with MSVC a while ago. Suhaib > -----Original Message----- > From: legalize@mail.xmission.com [ mailto:legalize@mail.xmission.com]On > Behalf Of Rich Thomson > Sent: Sunday, August 22, 1999 1:05 PM > To: Chris Faylor > Cc: Kendall Bennett; Suhaib Siddiqi; cygwin-xfree@sourceware.cygnus.com; > Rich Thomson > Subject: Re: Win32 version of XFree86 > > > > Hi, > > There isn't any need to cc: me on messages regarding a port of Xfree86 > to Windows. In fact, I've unsubscribed from all xfree86 mailing > lists. > > My interest is in a DirectX based server, not a port of Xfree86. I > just don't think a port of xfree86 is the best path to a DirectX X > server. I think you will get a better server by starting with the > X11R6.4 sample server code and starting with a very simple X server hw > layer that just pushes spans to the DirectDraw code. > > The X server is already plenty portable enough on its own for things > like the necessary O/S services. Everything in the core X server code > is written very portably. You may need to adjust the imake environment > to suit newer compiler switches and so-on, but you should not need to > make any changes to the X server core code. The X library code has > already been built on Win32, so some Win32 environment support is > already present in X. I believe they punted on xterm because of its > pty usage, but it is a special case. Perhaps you could get xterm > compiled with gcc/cygwin. At any rate, I'm more interested in a server > before xterm. > > The difficulty in a Win32 non-DirectX X server in the past has had to > do with the way resources are shared under X and under Windows. The > two are not very compatible when it comes to things like colormap > management and focus management and so-on. Trying to make top-level X > client windows look like Win32 app client windows is annoying and > tedious. > > DirectX lets you do away with GDI and take over the screen, which is > exactly what an X server wants to do when it starts. No hw-specific > drivers are needed because you rely on DirectDraw to provide the device > abstraction. The X sample server is coded to handle memory-mapped > frame buffers quite efficiently all in software. From a basic working > server you begin optimizing higher-level requests from there. > > That is the X server I'm interested in making. Since a DX-based server > wouldn't need any of xfree86/hw code, all that code just goes away. > But wait, you just threw out 90% of the xfree86 server effort. Is > there any reason to keep the remaining 10%? The remaining 10% of code > consists of startup/shutdown code, font code, input device code, and > the OS layer code. All of this code in xfree86 is from a unix > viewpoint, so it must be changed anyway for a Win32 DirectX based X > server. > > The startup/shutdown code can't be used from xfree86 because device > management is totally different under Windows. > > The X server only requires a few routines for supporting the basic > keyboard and mouse events and a few more for extension devices (like a > gamepad/joystick). We can use Windows event mechanism, or use > DirectInput for device input. Either way, we can't use the xfree86 > code. > > The font code is probably stock X server font code, which means it > can't take advantage of Windows fonts. Eventually you'd like to be > able to take advantage of Windows installed fonts for a DirectX based > server, so you'd need to adjust the font code. > > The OS layer code is easy to supply for native Win32. For several of > the functions, you can use the unix equivalent just fine on Win32 > (things like opening files, opening socket connections, etc). > > So, in the end, you can't hardly use any of the xfree86 code in a very > useful way for a native Win32 directX-based X server. The part of the > code that you can reuse comes from the core sample server, not from > xfree86. > > If you tried to use the xfree86 code, you have to deal with the way it > wants to talk directly to all the different hardware out there. The > core X server itself isn't coded this way, the xfree86 portions of it > are. The xfree86 portions include assembly code, unix-oriented I/O > code, unix-oriented device management code. For a DirectX server these > are replaced with DirectDraw and Win32. > > So in the end I came to the conclusion that trying to port Xfree86 > would be more work than just porting the core sample server itself. > This is usually not the case, because normally you don't have a > HW-independent abstraction beneath you when porting the X server. > Usually you have to do what Xfree86 has done and support the different > hardware directly. Its tedious, cumbersome and *lots* of code for the > amount of hardware in the PC world today. > > But with a DirectX PC, MS and the hardware vendor have already provided > the abstraction that takes away the complexity of the hardware. > > You are, of course, free to pursue your own direction. However, I am > more interested in making the X server I've described in this message. > > -- Rich > From ssiddiqi@inspirepharm.com Sun Aug 22 13:35:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 22 Aug 1999 13:35:00 -0000 Subject: Cygwin32 and GPL concerns References: <37C057E4.3F7276B9@mozilla.org> Message-ID: > -----Original Message----- > From: owner-devel@XFree86.Org [ mailto:owner-devel@XFree86.Org]On Behalf > Of Mike Shaver > Sent: Sunday, August 22, 1999 4:05 PM > To: devel@XFree86.Org > Subject: Re: Cygwin32 and GPL concerns > > > Lynn Winebarger wrote: > > > > On Sun, 22 Aug 1999, Harald Koenig wrote: > > > > > you still haven't got it: the XFree86 license allows > me/everone to build > > > commercial/closed products for which I do _not_ release sources. > > > linking against GPL won't allow me to do so anymore. > > > > Yes, and the second part is only true if it's a static link, > or if the > > GPL'ed library is non-standard or if it is the only > implementation of the > > API it defines (I believe these are the criteria RMS uses to decide if > > the calling code is derivative of the library). > > Perhaps fortunately, RMS is not a lawyer or judge, and so his definition > of ``derivative work'' is not particularily interesting from a legal > perspective. If you want to know if you can distribute a > GPL-library-linked binary without source, you should consult a lawyer in > your jurisdiction of choice. > > Mike Ummm.. Mozilla does the same what I am syaing compilation using GPL'ed tools. The Mozilla URL recommeds to compile on Win32 download the code, and download Cygwin from Cygnus... compile it yourself. Regardless, the people who are willing to use MSVC and X11R6.4 plus DirectX, are welcome too. I do not have experience with directX, so I would need help here. I do had patched X11R6.4 code to the extent that Xprt, and Xvfb servers compiles too using MSVC. Now it is a matter of adding a DirectX code to it. Suhaib > > -- > 262765.49 254574.35 > From shaver@mozilla.org Sun Aug 22 13:43:00 1999 From: shaver@mozilla.org (Mike Shaver) Date: Sun, 22 Aug 1999 13:43:00 -0000 Subject: Cygwin32 and GPL concerns References: Message-ID: <37C05FA1.B76C14E8@mozilla.org> "Suhaib M. Siddiqi" wrote: > > Perhaps fortunately, RMS is not a lawyer or judge, and so his definition > > of ``derivative work'' is not particularily interesting from a legal > > perspective. If you want to know if you can distribute a > > GPL-library-linked binary without source, you should consult a lawyer in > > your jurisdiction of choice. > > > > Mike > > Ummm.. Mozilla does the same what I am syaing compilation using GPL'ed > tools. The Mozilla URL recommeds to compile on Win32 download the > code, and download Cygwin from Cygnus... compile it yourself. Um, no. We use some of the cygwin tools (cp, rm and date), but no libraries and not the compiler. We don't have any GPL-taint issues here. Trust me on this one. And regardless, my point was that RMS's interpretation isn't really relevant to the discussion at hand. I'm done now. Mike -- 264679.76 256387.92 From ssiddiqi@ipass.net Sun Aug 22 13:49:00 1999 From: ssiddiqi@ipass.net (Suhaib M. Siddiqi) Date: Sun, 22 Aug 1999 13:49:00 -0000 Subject: Win32 version of XFree86 References: <199908222040.OAA16907@xmission.xmission.com> Message-ID: I do have and those patches I did not release to public yet. I have patched X11R6.4 to the extent that compiles with MSVC 6.0 without problems. It compiles all the libraries as DLLs, as opposed to orginal X consortium code where most of the libs compile as static libs. I could even compile Xprt, Xnest and Xvfb servers. Xterm does not compile because MSVC has no pty's but I do have a solution for that too. Now if you are willing to help and write the DirectX/DirectInput you are certainly most welcome. I would be glad to share the patches with any one who is willing to take over the DirectX work. I do not have any experience with DirectX/DirectInput so do not expect I would be a big help in writing DirectX code. Suhaib > -----Original Message----- > From: legalize@mail.xmission.com [ mailto:legalize@mail.xmission.com]On > Behalf Of Rich Thomson > Sent: Sunday, August 22, 1999 4:40 PM > To: ssiddiqi@ipass.net > Cc: Kendall Bennett > Subject: Re: Win32 version of XFree86 > > > > In article < LOBBLPGIHMIEGBEAFDMCGEMCCAAA.ssiddiqi@inspirepharm.com >, > "Suhaib M. Siddiqi" writes: > > > I have sorted out most of the core X11R6.x with MSVC a while ago. > > If you have changes to the Win32 support in the imake environment, > then that would be something we could share. Diffs against the > X11R6.4 source would be best, but whole files are OK too. > > -- Rich > From ssiddiqi@inspirepharm.com Sun Aug 22 18:29:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Sun, 22 Aug 1999 18:29:00 -0000 Subject: X11 dynamic linking library problem References: <01BEED4E.2CE2B6C0@NTYANTAI> Message-ID: > Hello, > I downloaded x11r6.4_lesstif.zip, and > tried to compile one small X client program with MSVC > successfully. But when > I run it, it crashed with the following statement: > window=XCreateSimpleWindow(disp, > RootWindow(disp,0),100,100,300,300,2,1,0); > Where window is NULL which meant failure to generate one window. > Of course > my X server had been started up ready without any question. I > suspected the > failure reason due to the dynamic linking library X11.lib. > I also tried the same problem with Cygwin -B20.1 compiler but > ended up with > error of failure to find the procedure entry point of X11. The X11.dll uses MSVCRT from Developers Studio 6.0. All the clients compiled and passed the test. You would find several of them in the bin directory. Be aware that MSVC might not allow you to create some Widgets, while Cygwin may let you do that because Cygwin emulates UNIX layer. What do you mean by "procedure entry point of X11"? There are two versions of X11 development suite for Cygwin. One is for Cygwin B20.1 and other for snapshots. The snapshot suite is marked x11r6.4-cygwin-ss-deb.tar.gz, which means Development SnapShot. If you use ss-dev version you will get an error _ctype_ entry point not found in cygwin1.dll. All the clients for Cygwin and also for MSVCRT compiled and worked with Exceed, PC-Xware and Netmage X-servers. Therefore I do not think anything is wrong with the X11R6.4 development suite for Cygwin or MSVCRT. I have myself used them for several X11 applications and did not have problem. > > However if I used your static link X11 library which was downloaded from > http://freehosting1.at.webjump.com/38173c2dd/si/siddiqi-webjump/x1 > 1r6.4-cygwin-b20.1.tar.gz with Cygwin -B20.1 compiler, it worked. There is no statically linked X11 library which I distribute. The X11 for Cygwin B20.1 also contains a libX11.dll and a libx11.a which is just a place holder. > > Looking forward to your kind reply. > > Regards. > > From tetsuji@MailAndNews.com Sun Aug 22 19:08:00 1999 From: tetsuji@MailAndNews.com (Tetsuji Rai) Date: Sun, 22 Aug 1999 19:08:00 -0000 Subject: make World error Message-ID: <199908230208.LAA00643@tetsu.localdomain> Hi, I'm a quite new user of cygwin. At first, I bunzip2 and untared the xc-?.tar.bz2 files, and run "make World|tee world.log". or whatever. Then make says "make : /bin/sh command not found". Actually, sh.exe is in /cygnus/cygwin-b20/H-i586-cygwin32/bin, but make cannot refer to /bin/sh. How can I do it? I guess it's related to many other things......but cannot find it in faq. Thanks in advance. -Tetsuji Rai -- Tetsuji Rai Tokyo Japan PPL 2476457 tetsuji@MailAndNews.com Aviation Jokes: http://www.geocities.com/CapeCanaveral/Station/9416/ fax: +1-708-570-4868 (in the US) ICQ: 45395250 From cgf@cygnus.com Mon Aug 23 16:43:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Mon, 23 Aug 1999 16:43:00 -0000 Subject: make World error References: <199908230208.LAA00643@tetsu.localdomain> Message-ID: <19990823194535.A16770@cygnus.com> On Mon, Aug 23, 1999 at 11:08:33AM +0900, Tetsuji Rai wrote: > I'm a quite new user of cygwin. At first, I bunzip2 and untared the >xc-?.tar.bz2 files, and run "make World|tee world.log". or whatever. Then >make says "make : /bin/sh command not found". Actually, sh.exe is in >/cygnus/cygwin-b20/H-i586-cygwin32/bin, but make cannot refer to /bin/sh. How >can I do it? I guess it's related to many other things......but cannot find >it in faq. If you are this new to cygwin, you probably should not even be considering jumping into this project yet. Anyway, try sending this problem to the main mailing list. It's offtopic here. -chris From ssiddiqi@inspirepharm.com Mon Aug 23 18:14:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Mon, 23 Aug 1999 18:14:00 -0000 Subject: make World error References: <19990823194535.A16770@cygnus.com> Message-ID: Please note this is a project in progress. The source code and patches would change as we make progress. First of all, due to some typical UNIX style assembly language at the monet it not possible to extract Xc-*.tar code with Cygwin default mount. You must unmount and remount with -b option so assembly code can be read and written in UNIX binary format. Check Cygwin FAQ at http://sourceware.cygnus.com on how to do a binary mount. If you are interested only in Xfree86 libraries you may be better of downloading the precompiled binaries. make World >& World.log is the Xfree86 recommended way to go. Full compilation takes 5 hours on my 500 MHz PIII machine. Therefore you must have a plenty of time at hand if you intend to work with code and compile it yourself. At the stage I rather type make World and watch the screen, break when I see the error, fix and restart again. The Source code at the Sourceware server sgould compile without errors but there is no warranty for it. Any further questions should be addressed to cygwin-xfree mailing list at cygwin-xfree@sourceware.cygnus.com Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Chris > Faylor > Sent: Monday, August 23, 1999 7:46 PM > To: Tetsuji Rai > Cc: cygwin-xfree@sourceware.cygnus.com > Subject: Re: make World error > > > On Mon, Aug 23, 1999 at 11:08:33AM +0900, Tetsuji Rai wrote: > > I'm a quite new user of cygwin. At first, I bunzip2 and untared the > >xc-?.tar.bz2 files, and run "make World|tee world.log". or > whatever. Then > >make says "make : /bin/sh command not found". Actually, sh.exe is in > >/cygnus/cygwin-b20/H-i586-cygwin32/bin, but make cannot refer to > /bin/sh. How > >can I do it? I guess it's related to many other > things......but cannot find > >it in faq. > > If you are this new to cygwin, you probably should not even be > considering jumping into this project yet. Anyway, try sending this > problem to the main mailing list. > > It's offtopic here. > > -chris > From Ssiddiqi@InspirePharm.Com Wed Aug 25 04:10:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Wed, 25 Aug 1999 04:10:00 -0000 Subject: X, OpenDX and cygwin References: <000901beeed1$1029c120$64091ba0@dougal> Message-ID: If your ISP server is listed in ORBS database as an OpenRelay SMTP server and being abused by hackers/spammers, then Cygwin lists would reject the mails originating from your server. This is being done to keep spamers away from Cygwin mailing lists. The XFree port is not complete yet. This a work in progress. TheMI/X will not work because it uses X11R5 libs which no one in the world uses any more, at not on Windows. Beside MI/X is no more free. You need to pay $25.00 per copy to have outdated X-server with stdin/stdout craps ;-) Suhaib > -----Original Message----- > From: Paul Baxter [ mailto:paje@globalnet.co.uk ] > Sent: Wednesday, August 25, 1999 4:09 AM > To: Ssiddiqi@inspirepharm.com > Subject: X, OpenDX and cygwin > > > Originally sent to cygwin Xfree mailing list, but rejected by mailer. > > Apologies for sending directly to you, Suhaib. > > -------------------------------------------------- > > Hi all > I've looked through the archive here and on general cygwin. > I've also looked at Suhaib's excellent X server work, but am still unsure > about the state of X server's for cygwin or win32. > > I'm trying to evaluate Suhaib's port of OpenDX to cygwin (4.0.6) > and wonder > if there's an open source X server which will work for this. > (I think Mi/X doesn't work - the only other one I know) > > I got the impression that the binaries on Suhaib's jump station > may not yet > be ready for such a feat. > > Any comments or recommendations appreciated. > > Great work Suhaib, Mumit and everyone else > > Paul Baxter > > > From Ssiddiqi@InspirePharm.Com Wed Aug 25 14:49:00 1999 From: Ssiddiqi@InspirePharm.Com (Suhaib Siddiqi) Date: Wed, 25 Aug 1999 14:49:00 -0000 Subject: 3.9.15 Win32 patches Message-ID: I have uploaded the patches for publicly available Xfree86 3.9.15 snapshots, at ftp://sourceware.cygnus.com/pub/cygwin/xfree The patches are intended for developers who are wokring on Win32 port. You will need to download XFree96 3.9.15 from XFree86.org. No binaries are available at the moment. 1) XFree86 3.9.15 source tree compiles using GCC under Cygwin. 2) Xprt. Xnest and Xvfb servers compiles and work. 3) All the libraries and Clients compiles and work. 4) The libs are build as DLL (Dynamically loaded library). 5) The other X's (X-servers) are still broken due to missing Win32 devices support. 6) Work on Win32 devices support is in progress. 7) At the moment it is not possible to build XFree86 3.9.15 with #define MakeDlModules. Have fun, and let me know if you find something broken, particulry if libs and clients do not work. Suhaib.