March 2004 - Wine-Devel - list.winehq.org

Re: winemaker fixes

by Dimitrie O. Paun

On Tue, 2 Mar 2004, Francois Gouget wrote: > winemaker is pretty broken since it has been patched to call winegcc. I > suspect it was not tested. Hey, I can't do everything! :))) I just wanted to get the ball rolling. > We must specify '-lmsvcrt' if using the msvcrt. Please don't, it's not needed. If you want to use msvcrt, please pass the -mno-cygwin switch. if that doesn' work, it's a bug in winegcc. > There is still work to do: > > 1. Linking with uuid is broken. I suspect winegcc finds the Unix > /lib/libuuid.so first and links with that instead of with our libuuid.a > library. That shouldn't happen. Can you please run winegcc with the -v flag, and send the output my way please? > 2. wrc does not find 'windows.h' (yes, some RC files #include Win32 > headers). wrc should know about the location of the headers like winegcc > (since our Makefile don't know anything about where the Wine headers are > anymore). I've verified the source and it should. Maybe you can produce a --debug=FF trace? > 4. We have lost the autoconf integration. We should encapsulate our macros so they can conveniently be used by people in their configure.ac scripts. I think that's the proper way to get autoconf integration. > 5. Nothing works if Wine has not been installed. This is quite > impractical for Wine developers. It's true, but there are many reasons you need to install Wine to be able to use Winelib. I doubt it will change in the near future. > 6. winegcc is not rebuilt if the '--prefix' changes. Maybe AJ can fix the Makefile. I think winegcc.o should depend on the Makefile. > 7. Building dlls does not work yet but that was expected and Dimi is > working on it. In progress :) -- Dimi.

March 2, 2004

Re: winegcc: portability

by Dimitrie O. Paun

On March 2, 2004 2:19 am, Kirill Smelkov wrote: > I think that from this point of view it is desirable to add the options to > generated Makefiles, or at least do some checking for them > (this was done originally). Yes. I just wanted to know where is the proper place for them. If MinGW have them turned on my default, we should do so in winegcc. If not, we should do it in winemaker. Feel free to submit winemaker patches, I'm not hacking at it ATM. -- Dimi.

March 2, 2004

Re: Cross compiling Wine with MinGW

by Hans Leidekker

> ifsmgr.vxd$(DLLEXT): ifsmgr.vxd/ifsmgr.vxd$(DLLEXT) > $(RM) $@ && $(LN_S) ifsmgr.vxd/ifsmgr.vxd$(DLLEXT) $@ > > because, if $(DLLEXT) is empty, it will try to create a link > with a name that's already there as a directory. Would it be an idea to rename vxd directories like ifsmgr.vxd to ifsmgr? Or do you foresee conflicts? After all, .acm, .ocx and .drv exist besides .dll without the subdirectories bearing a corresponding suffix. -Hans

March 2, 2004

Re: Cross compiling Wine with MinGW

by Hans Leidekker

On Monday 01 March 2004 18:55, Juan Lang wrote: > > additionally > > link to ws2_32 it builds on MinGW as well as Wine. > > You have to link to ws2_32? That's interesting, I > didn't. I submitted a patch, minus that bit. Yes you need to, I have tested this. You don't need it on Wine because there you somehow get inet_addr indirectly, but on MinGW (and MSVC) you sure need it otherwise it won't build. > > MinGW and MSVC versions of winsock2.h have the > > defines, so > > I guess we need to add them. Attached patch does so. > > Could you submit to wine-patches? Thanks! I intended to do so but I addressed it to wine-devel twice, so here it is again. This fixes cross compilation of wsock32. -Hans Changelog: add protocol type constants.

March 2, 2004

Re: Native NetBSD audio driver

by Yorick Hardy

I started now with the integration of the OSS and NetBSD audio drivers. Before I get too far, I would like to hear suggestions/criticisms. 1) I created the directory dlls/winmm/drvcommon (perhaps there is a better name ?) 2) moved dlls/winmm/wineoss/oss.c and dlls/winmm/winenbsd/nbsd.c to the single integrated file dlls/winmm/drvcommon/drv.c. 3) renamed the files dlls/winmm/wineoss/oss.h and dlls/winmm/winenbsd/nbsd.h to dlls/winmm/wineoss/drv.h and dlls/winmm/winenbsd/drv.h respectively. 4) Update the respective Makefile.in to use the integrated dlls/winmm/drvcommon/drv.c The idea is that eventually winenbsd and wineoss only have the drv.h and the spec file. drv.h will define all driver specific names/functions. I must stress that I am only concerned with the OSS and NetBSD drivers at the moment. Is this too much? Or can someone suggest a better solution? Kind regards, -- Yorick Hardy Tel: +2711 489 3640 | Fax: +2711 489 2067 | Office: C-Ring 517 Auckland Park Campus | Rand Afrikaans University | South Africa Department of Applied Mathematics : http://general.rau.ac.za/apm Standard Bank Academy for Information Technology : http://csweb.rau.ac.za

March 2, 2004

Re: Office '97 test: installer good, app not usable

by Boaz Harrosh

Dan Kegel wrote: > Sigh. I guess I'll dig up the copy of Crossover I bought for testing > a while ago. Wonder if that even works with such an old Linux, though... > - Dan > Once you run Crossover and create a dir REG and other stuff, you can than use that fake_windows with your up-to-date wine. Just point your ~/.wine/config the cxoffice way. Also copy some of the cxoffice config stuff to wine's. Cxoffice is grate as a WineCfg :/

March 2, 2004

Re: winegcc: portability

by Kirill Smelkov

1 Март 2004 10:13, Dimitrie O. Paun написал: > On March 1, 2004 1:50 am, Kirill Smelkov wrote: > > And what about next (removed from winemaker by your recent patch) > > -fpermissive, > > -fms-extensions > > -fno-for-scope > > ? > > > > They are very handy when porting win32 apps. > > Are these by default turned on on MinGW's gcc? If so, > I'll add them. If not, you can simply specify them on > the command line. As I don't use it, I can say nothing about MinGW's gcc. But if i take it right, the goal of winemaker is to provide straight and acheless way for porting win32 apps to wine. I think that from this point of view it is desirable to add the options to generated Makefiles, or at least do some checking for them (this was done originally). -- Kirill.

March 2, 2004

Office '97 test: installer good, app not usable

by Dan Kegel

A friend wanted to borrow my old laptop while she's in the hospital, so I scurried around and got wvdial and fvwm95 working on my old 133MHz 48MB RAM, 1.1GB disk Redhat 6.2 laptop, then built the latest Wine. Ran into two minor problems, but basically it built just fine. Took all night, but hey, what do you expect for a 133MHz laptop? Then the real test: Office '97. The installer worked very, very well. Only flaw was some letters were cut off on the right hand side of the pacifier dialogs during install. This is the best I've seen it in the four or five years I've been trying this. Running Office was another matter. I only tested it a bit, but there's a display problem: text is displayed invisible in the main document pane on the same line you're editing. If you refresh, everything's there. Not terribly usable. Sigh. I guess I'll dig up the copy of Crossover I bought for testing a while ago. Wonder if that even works with such an old Linux, though... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

March 2, 2004

Re: Problems with CHtmlView class in WINE

by Boaz Harrosh

vishal wable wrote: > Respected Sir, > > I am trying to run a MFC application in Red Hat Linux 8 using > WINE.(Latest Version). > I have used a MFC class "CHtmlView" in order to display html pages. > Following line of code does that for me. > > Navigate2( "MyPage.html",NULL,NULL); > > In WINE i get the following error when trying to do so. > > "Cannot create an empty document" > > and the application crashes. > > Could you please help me to solve this problem. > thank you, > > > <http://us.rd.yahoo.com/mailtag_us/*http://antispam.yahoo.com/tools> You need IE5.5 or up Installed on your Wine setup - First install dcom95 (or dcom98) than IE6 setup. - Search mailing archives and/or website. Some one has posted a script that does the download and the Installation automatically. once there it should work no problems. Free Life Boaz

March 2, 2004

Close button on MFC dockable windows

by Justin Chevrier

Several programs: eg: Powergrab: http://www.cosmicwolf.com SCB Demo3: http://adam.stup.ac.ru/Developer/ ArticleDetail.aspx?ar=318&l=n&mi=10&mic=40 that make use of MFC to do things like dockable windows don't properly draw the close button on docked windows. Instead of an 'x' it looked more like an 'r'. After some investigation and traces I saw that wine was substituting Arial in for Marlett when Marlett was specified with a DEFAULT_CHARSET. I changed the behaviour to instead load 'webdings' when this situation was encountered. This changed the font drawn on the button from an Arial 'r' to a Webding close 'x' character. Unfortunately it was drawn well below the actual button. I am not sure of the correct way to fix this. I have included a changed line: if(ppem <= startsz || ppem > endsz) that corrects this but I doubt it's correct. Justin Chevrier Changelog: Allow MFC programs that dock windows to draw a correct close button. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

March 2, 2004