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

MSTS installer - files inside setupenu.dll

by Frank Eising

I am trying to get the Train SImulator setup working. Last time I debugged it I found that the setup looks for jpeg images in a certain directory to set up the setup menu. They are not found, because those files are non-existent on the cdrom. They are inside setupenu.dll. Anyone knows what kind of thing needs to be implemented, in order to make files inside a dll accessable by wine? I could not find any errors in the debug messages referring to it. Frank -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

Aug. 22, 2004

Re: [QUARTZDRV] Preliminary support for native OS X graphics

by Roderick Colenbrander

Quartz support is ofcourse great but without a patch it isn't very usefull ;) Roderick Colenbrander > This patch includes a partially graphics driver for OS X. Everything > except the basic window management functions of the user driver are > stubs. The patch depends on Pierre d'Herbemont's "Support for > disabling symbols import in WineBuild based on a prefix." > > Changelog: > Rib Rdb <ribrdb(a)gmail.com> > Add preliminary support for native graphics on Mac OS X. > -- Superg�nstige DSL-Tarife + WLAN-Router f�r 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl

Aug. 22, 2004

Re: [Darwine] Beginnings of quartzdrv

by Rib Rdb

I tried SDL's CPS code, but aparently it only works with Cocoa. I tries searching the internet for c programs that used it, and I only found one which also didn't work. I'd be fine to use Cocoa (there'd probably be fewer name conflicts), but I couldn't get the Obj-C files to build. On Sun, 22 Aug 2004 13:11:17 +0200, Pierre d'Herbemont <stegefin(a)free.fr> wrote: > Rib, > > If you want to get Docking support see the SDL code for it [1], > especially the CPS (docking) related code. SDL can set up a dock item > without using the .app bundle. I think it will be enough to have get > window focus. > > I sent the patch you were talking about to then wine-patches [Support > for disabling symbols import in WineBuild based on a prefix.] > > Pierre. > > [1] > http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/src/main/macosx/SDLMain.m? > rev=1.11&content-type=text/x-cvsweb-markup > > Le 22 août 04, à 09:57, Rib Rdb a écrit : > > > > > Attached is a very preliminary driver for native graphics on OS X. So > > far all it does is let you make windows. No events or drawing work > > yet (I was baffled by the GetDC function. It looked like the existing > > drivers only call windows functions, and I didn't see any way for > > setting the window's context.) To compile this requires a patch by > > Pierre d'Herbemont to deal with conflicting function names in windows > > and Carbon. He said he will send it here. > > Also, to get the windows to focus, you have to place the executable in > > an application bundle. I just took one I had sitting around, copied > > the wine binary over the executable in the bundle and ran it from the > > commandline like so: > > /Users/ribrdb/Desktop/winemine.app/Contents/MacOS/CarbonTest winemine > > > > Things are getting busy with work, so I'm not sure when I'll have more > > time to work on this. > > <quartzdrv.tar.gz> >

Aug. 22, 2004

Re: iostream and msvcrt?

by Boaz Harrosh

Scott Snell wrote: >which throws up a world of errors, such as: > >In file included from ../stlport/cstdlib:25, >from ../stlport/stl/debug/_debug.c:160, >from ../stlport/stl/debug/_debug.h:418, >from ../stlport/utility:40, >from dll_main.cpp:35: >/usr/include/c++/3.3.2/cstdlib:97: error: `div' not declared >/usr/include/c++/3.3.2/cstdlib:102: error: `ldiv' not declared >/usr/include/c++/3.3.2/cstdlib: In function `ldiv_t std::div(long int, long >int)': > >I'm sure its something simple but I'm still not comfortable around >gcc/winegcc. > >thanks, > >Scott. > > > >>-----Original Message----- >>From: Dimitrie O. Paun [SMTP:dpaun(a)rogers.com] >> >> >> >>>>adding a path pointing to /include/wine/MSVCRT. >>>> >>>> >>>> >>No, you shouldn't need that. You just need to make sure you pass >>the -mno-cygwin flag to winegcc/wineg++. >> >>-- >>Dimi. >> >> You need to have your stlport/config/stl_wine.h (I based mine on stl_mycomp.h, not stl_gcc.h) and change /stlport/config/stlcomp.h to include it (based on a WINE_GCC flag). You need to do that because of the way STLPort works with headers. you must put a path that will Definitely select wine/msvcrt as the source of stdc. I used ../msvcrt in the header and than Just fixed up the -I list in makefiles (and the WINE_GCC flag or is there a flag that is defined by wingcc). Free Life Boaz

Aug. 22, 2004

Re: [Darwine] Beginnings of quartzdrv

by Pierre d'Herbemont

Rib, If you want to get Docking support see the SDL code for it [1], especially the CPS (docking) related code. SDL can set up a dock item without using the .app bundle. I think it will be enough to have get window focus. I sent the patch you were talking about to then wine-patches [Support for disabling symbols import in WineBuild based on a prefix.] Pierre. [1] http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/src/main/macosx/SDLMain.m? rev=1.11&content-type=text/x-cvsweb-markup Le 22 août 04, à 09:57, Rib Rdb a écrit : > Attached is a very preliminary driver for native graphics on OS X. So > far all it does is let you make windows. No events or drawing work > yet (I was baffled by the GetDC function. It looked like the existing > drivers only call windows functions, and I didn't see any way for > setting the window's context.) To compile this requires a patch by > Pierre d'Herbemont to deal with conflicting function names in windows > and Carbon. He said he will send it here. > Also, to get the windows to focus, you have to place the executable in > an application bundle. I just took one I had sitting around, copied > the wine binary over the executable in the bundle and ran it from the > commandline like so: > /Users/ribrdb/Desktop/winemine.app/Contents/MacOS/CarbonTest winemine > > Things are getting busy with work, so I'm not sure when I'll have more > time to work on this. > <quartzdrv.tar.gz>

Aug. 22, 2004

Beginnings of quartzdrv

by Rib Rdb

Attached is a very preliminary driver for native graphics on OS X. So far all it does is let you make windows. No events or drawing work yet (I was baffled by the GetDC function. It looked like the existing drivers only call windows functions, and I didn't see any way for setting the window's context.) To compile this requires a patch by Pierre d'Herbemont to deal with conflicting function names in windows and Carbon. He said he will send it here. Also, to get the windows to focus, you have to place the executable in an application bundle. I just took one I had sitting around, copied the wine binary over the executable in the bundle and ran it from the commandline like so: /Users/ribrdb/Desktop/winemine.app/Contents/MacOS/CarbonTest winemine Things are getting busy with work, so I'm not sure when I'll have more time to work on this.

Aug. 22, 2004

More Darwine news (was Re: New Darwine Binary Released)

by Jim White

Sanjay Connare wrote: > Hey All, I am proud and happy to announce the release of a new binary > labeled Darwine 20040820 DP. This binary is based upon the 20040813 > wine release. > ... Thought I would post a follow-up as Sanjay neglected to include a link to the new binary: http://darwine.opendarwin.org/ http://sourceforge.net/projects/darwine/ Other Darwine news is that there was an interview with moi on osViews: > the article(s) are posted > > Text: > http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=20… > > Broadcast: > http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=20… > > > Thank you for your help and support. It is greatly appreciated. I > hope this helps bring about increased awareness for the Darwine project. > > -- > Kelly McNeill > OSV And perhaps the most interesting news is that Darwine's lead developer Pierre d'Herbemont has sucessfully ported QEMU (fast X86 emulator) to Mac OS X: > QEMU on Mac OS X > by Pierre d'Herbemont > 2004-07-04 at 11:07:13 > > I am proud to announce that QEMU is now working on Mac OS X. > • Original announcement on the qemu-devel list > • Download the installer for Mac OS X > • Screenshots of QEMU running on Mac OS X > • The FreeOSZoo, to download ready-to-run images of QEMU virtual > computers, pre-installed with a Free Operating System and a set of > popular free software. > > I would like to thanks Matt Reda for its collaboration. http://www.freeoszoo.org/download.php Jim White

Aug. 22, 2004

Re: Wrong call convention for SHAllocShared & co?

by Ivan Leo Puoti

>Hence my confusion and my call for help. The solution that comes in mind is write a test program and find out. Ivan.

Aug. 21, 2004

Re: Wrong call convention for SHAllocShared & co?

by Francois Gouget

On Sun, 22 Aug 2004, Ivan Leo Puoti wrote: > > So who's right? The platform SDK that says this is a cdecl function or > > Wine's headers? > If the SDK is wrong and is diffrent from the windows implementation, then > programs calling that function will have > problems bacause of imcompatible headers between the ones used to build windows > and the SDK ones used to build the program, no? Yes and that would seem to indicate that the Platform SDK is correct. However if Wine's implementation is wrong then Windows applications that call this API should crash and we should have noticed, no? So that seems to indicate that Wine's implementation must be correct. Hence my confusion and my call for help. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

Aug. 21, 2004

Re: Wrong call convention for SHAllocShared & co?

by Ivan Leo Puoti

> So who's right? The platform SDK that says this is a cdecl function or > Wine's headers? If the SDK is wrong and is diffrent from the windows implementation, then programs calling that function will have problems bacause of imcompatible headers between the ones used to build windows and the SDK ones used to build the program, no? Ivan.

Aug. 21, 2004