January 2003 - Wine-Devel - list.winehq.org

Re: wxWindows: it's official!

by Francois Gouget

On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: [...] > 2. Francois' patch that fixes winsock.h I'll try to complete it shortly. > 3. My patch that adds io.h I'm not sure this one is a good idea. We already have an io.h in the msvcrt directory as we need it for compatibility with msvcrt. So with your patch we would have: include/io.h include/msvcrt/io.h That seems like an include order nightmare. Furthermore your header only contains: int access(const char *__path, int __amode); If you use that function you will have to link with the msvcrt. Ortherwise your Winelib application is going to call the glibc access function which will choke on the Windows paths 'c:\Temp\xxx.tmp'. So it seems like you might as well use the msvcrt headers... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Jan. 7, 2003

Re: getting started

by Dimitrie O. Paun

On January 7, 2003 02:25 pm, Francois Gouget wrote: > * winemaker > The assumption is that you have a Windows application (complete with > CR/LF), most likely based on Visual C++ and thus with no suitable > makefiles. So winemaker's goal is to quickly generate suitable Makefiles > that will build Winelib applications/dlls from what it's given and fix > the simple issues in the source (CR/LF, #pragmas). The backend is > somewhat secondary. This touches on an issue that I'd like to avoid discussing now -- it deserves a separate thread. But just to note that the things you've mentioned are not mutually exclusive: -- winemaker has a one-time fixup mode as you mention, for Window specific things that are non portable. This is something good that should stay in winemaker. -- Yes, I agree we want to share more of the build system between Wine and Winelib apps. But my proposal is not counter to this: we should use winegcc in Wine as well. -- Having the make files portable between Wine/Linux/MinGW can only be a good thing, right? What I'm saying is that winemaker right now generates a lot of the linking/compiling code 'inline' inside the Makefile. All this stuff is now formalized in winegcc/winewrap, so it just makes sense to use those. We avoid duplication, and repeated breakage whenever we change something in the build. It's a win-win IMO. -- Dimi.

Jan. 7, 2003

Re: wineboot wininit patch 1

by Andreas Mohr

On Tue, Jan 07, 2003 at 08:19:19PM +0200, Shachar Shemesh wrote: > Changelog > Shachar Shemesh <winecode(a)sun.consumer.org.il> > > programs/wineboot/wineboot.c > > * Added a print to indicate to user that installation is done. Hmm, I'm not sure whether that's an entirely good idea. It's probably more flexible to have the script invoking wineboot print such a message instead. (some people might want to have "hidden" execution of wineboot configured) But OTOH you could also solve that issue by configuring wineboot to be silent in such a case, so maybe having such a message is a good thing after all. Andreas Mohr

Jan. 7, 2003

Re: wxWindows: it's official!

by Dimitrie O. Paun

Sorry about my previous attempt, I've pressed Send by mistake. And I've learned you can't stop KMail from sending... :) On January 7, 2003 02:09 pm, Francois Gouget wrote: > include/io.h > include/msvcrt/io.h > > That seems like an include order nightmare. Furthermore your header only > contains: > int access(const char *__path, int __amode); It's a big problematic, but not much. winegcc get this right anyway, and I can't see how it can be a problem: if you use msvcrt, you first have to include those headers. If not, they are not in the search path, so they don't exist. What scenario to you forsee where this can be a problem. > If you use that function you will have to link with the msvcrt. > Ortherwise your Winelib application is going to call the glibc access > function which will choke on the Windows paths 'c:\Temp\xxx.tmp'. So it > seems like you might as well use the msvcrt headers... That's the user's choice. We need to support io.h, mingw has it, cygwin has it. If we provide it only in msvcrt, we force everybody to use msvcrt, which is not right IMO. Thing is, the cygwin io.h contains only these definitions: extern long get_osfhandle(int); extern int setmode (int __fd, int __mode); int access(const char *__path, int __amode); You can check it out at: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/io.h… Since program not using msvcrt expect only these funtions, that's what we need to provide. I don't know what get_osfhandle(), and setmode() are (they are not standard Unix functions), I've added included only access(). -- Dimi.

Jan. 7, 2003

Re: wxWindows: it's official!

by Dimitrie O. Paun

On January 7, 2003 02:09 pm, Francois Gouget wrote: > On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: > [...] > > > 2. Francois' patch that fixes winsock.h > > I'll try to complete it shortly. > > > 3. My patch that adds io.h > > I'm not sure this one is a good idea. We already have an io.h in the > msvcrt directory as we need it for compatibility with msvcrt. So with > your patch we would have: > > include/io.h > include/msvcrt/io.h > > That seems like an include order nightmare. Furthermore your header only > contains: > int access(const char *__path, int __amode); > > If you use that function you will have to link with the msvcrt. > Ortherwise your Winelib application is going to call the glibc access > function which will choke on the Windows paths 'c:\Temp\xxx.tmp'. So it > seems like you might as well use the msvcrt headers... -- Dimi.

Jan. 7, 2003

wxWindows: it's official!

by Dimitrie O. Paun

That right, As of today, the patch I've sent a few days ago to the list has been integrated into the tree. Turns out that all those "#include <search.h>" were not needed, so the patch was even smaller than I thought! :) There are some things that need to go into the Wine tree before you can play with the wxWindows thing: 1. Dan's patch that fixes the RECT definition 2. Francois' patch that fixes winsock.h 3. My patch that adds io.h 4. My patch that adds wineg++ 5. My patch for tchar.h I think that's it... (I can't quite tell because I have the big NONAMELESS* patch in my tree). Alexandre, the wxWindows folks are eager to play with it, and have asked me to let them know when they can do so. Not a big deal, but if there are problems with any of these, please let me know so I can address them. -- Dimi.

Jan. 7, 2003

Re: A humble request for help

by Bill Medland

On January 6, 2003 03:29 am, Stefan Görling wrote: > Hi Everyone, > > I'm currently working on a thesis investigating how Open Source is > affected by the influence of money and the interests of commercial > companies. As the WINE efforts is the foundation of companies such as > Codeweavers, Transgaming and Lindows, it is interesting to study how > their entrance to the scene have affected the community. > snip > Bill Medland,ACCPAC Hi Stefan For preference can you make sure you use the full company name (ACCPAC International, Inc.) in the final thing. My work on Wine is part of my employment at ACCPAC. Basically we have an accounting software suite that we want people to be able to run under Linux. Currently the most cost-effective way for us to do that is to do our bit to ensure that Wine handles the Windows compatibility that we require. I find that I don't have the personal time to work on wine that others do; I am somewhat in awe of those that do. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

Jan. 7, 2003

Re: Wine Fun v0.3

by Sylvain Petreolle

If it hasnt already said : Some 'qt under windows' port is already in progress, see the guys from kde-cygwin.sf.net. --- Steven Edwards <steven_ed4153(a)yahoo.com> a écrit : > I remeber seeing in the mingw-users list someone was able to build QT > under Mingw although they > were having issues with the size of the library and programs due to > odd linking issues with > libstdc++. I dont remeber the exact details except that the resulting > binary was way larger then > the Unix or MS_VC counter-part. > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 7, 2003

Re: Wine Fun v0.3

by Dimitrie O. Paun

On January 7, 2003 11:23 am, Sylvain Petreolle wrote: > Some 'qt under windows' port is already in progress, see the guys from > kde-cygwin.sf.net. This won't do us any good -- it is using QT/X11, which ain't using much of Windows. We need QT/Windows, which is a different ball of wax. -- Dimi.

Jan. 7, 2003

Re: [RFC] __WINESRC__ & public headers

by Steven Edwards

> With the current efforts to cleanup our headers on __WINESRC__s, > I realized we are actually quite close to 'clean' header, something > that should allow us to compile Wine with other headers, such as > those from the w32api package that's part of mingw. Hehe I'm happy someone else wants to see this now. If there is someway we can script testing with other headers mabey with perl or something (now that MSYS has a decent perl) we can find where the WINE headers and others are not in sync. If such as system was in place I would be happy to add it to my testing routine. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 7, 2003