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

Re: PATCH: /dlls/ntdll/cdrom.c -- portability breakage

by Gerald Pfeifer

On Wed, 26 Mar 2003, Eric Pouech wrote: > Alexandre Julliard wrote: >> I think the code is wrong, we shouldn't store a Linux-only define in a >> Windows structure, we should use a Windows define. Any one knows what >> the right value should be? > the code is wrong (evil cut & paste IMO). we should use > IOCTL_CDROM_CURRENT_POSITION in FormatCode Is anyone going to patch this? CDROM_SeekAudioMSF() still fails to compile on FreeBSD (and is incorrect anyway, according to Alexandre and Eric) due to the use of cp->FormatCode = CDROM_MSF (Until this is fixed, it would be nice to have the following patch in, perhaps enhanced by a FIXME to make FreeBSD at least buildable again.) Thanks, Gerald Index: cdrom.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/cdrom.c,v retrieving revision 1.27 diff -u -3 -p -r1.27 cdrom.c --- cdrom.c 20 Mar 2003 21:59:50 -0000 1.27 +++ cdrom.c 1 Apr 2003 09:46:05 -0000 @@ -1045,7 +1045,9 @@ static DWORD CDROM_SeekAudioMSF(int dev, if (i <= toc.FirstTrack || i > toc.LastTrack+1) return STATUS_INVALID_PARAMETER; i--; - cp->FormatCode = CDROM_MSF; +#ifdef CDROM_MSF + cp->FormatCode = CDROM_MSF; +#endif cp->Control = toc.TrackData[i-toc.FirstTrack].Control; cp->ADR = toc.TrackData[i-toc.FirstTrack].Adr; cp->TrackNumber = toc.TrackData[i-toc.FirstTrack].TrackNumber;

April 1, 2003

Re: Whither specmaker?

by Mike Hearn

> FWIW, my problem is the oft-asked "How do I call functions in a Windows > DLL from an ELF process?" I appreciate WineLib is an option, and have > run into a number of snarls along that path: Well, see me discussing that with Bill a few days ago on the mailing list archives. Basically you have to make the whole ELF process into a WineLib app, at the moment you can't just call out from a standard linux binary into WineLib. IIRC mplayer does this by copy and pasting some wine code, then hacking it lots, even then that's only for codecs which are extremely simple programs. The basic problem is that there isn't any good way to initialise WineLib without using the wine loader program at the moment. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 1, 2003

Edit box input problem

by Brad Campbell

G'day all, I'm having a strange problem with any application that uses a delphi TMaskEdit component. I have knocked up a simple test application. http://www.seme.com.au/masktest.tgz It's in Borland Delphi 4 and contains both the .exe and the source for the interested or security conscious. Can someone else run this up on their wine build and see if it's doing the same thing? Under windows, it will only accept three numeric characters, under wine I'm unable to edit the field, it accepts over 3 characters and of any type, plus the first one or two character entries create a message storm as watched with a --debugmsg +message. Also, I'm willing to have a crack at fixing this, which .dll source should I start looking at? I also tried this with native comctl32, commdlg and oleaut32 dll's just in case. Problem remains. A normal Edit component works fine, and if I remove the mask it works fine, so it must be something the in the delphi code for the TMaskEdit component that is triggering a wine bug. -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

April 1, 2003

Whither specmaker?

by Kevin Cousins

Searching for an answer to my problem, comp.emulators.ms-windows.wine archives at google throw up a post [1] suggesting looking into tools/specmaker. Sources checked out from winehq.com CVS as of last week, updated today, have tools/specmaker as an empty directory. Where might I be able to investigate specmaker? Is specmaker still viable? FWIW, my problem is the oft-asked "How do I call functions in a Windows DLL from an ELF process?" I appreciate WineLib is an option, and have run into a number of snarls along that path: 1. I have created a .dll.so to wrap calls to the offending Windows DLL. Calls are made through static function pointers which have been initialised in the .dll.so by calls to GetProcAddress() from what would be the DllMain() function there. I've not managed to get Wine to call that DllMain() function of my .dll.so, other than through a breakpoint in the debugger, and explicitly calling the function at that time. This way, my code runs even returning from calls to the Windows DLL, but mysteriously, no output file is written! 2. I occasionally see user32.dll.so barf with a SEGV with the call stack mentioning res_146() deep during the first call to wine_dlopen(). I've also had a look at avifile, mplayer, and xine, to investigate how they do things. Linking avifile/plugins/libwin32/loader/libloader.a to my application means I can run as far as attempting to execute DllMain() on my Windows DLL before I see gut-wrenching a SEGV. What are other people doing? -- Kevin. [1]

April 1, 2003

Re: wine/ tools/winewrap.c tools/winegcc.c include ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > However, if we are to depend on winegcc/winewrap, we need to be able > to compile it anyway, no? And since it has a well defined semantics > (that's much more commonly available than the fork/exec), it's not > necessarily a bad addition. Yes, it's just that I don't like to add non-Unix APIs to the portability layer, but I guess there are good reasons for making an exception here. -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Re: Question about kernel32 resources

by Alexandre Julliard

Maxime Bellengé <maxime.bellenge(a)laposte.net> writes: > The different language group names are stored in the kernel32.dll > resources in a string table. They are indexed from 1 to 17 in the > win2k/winxp kernel32 dll. I doubt anything depends on that. I think it's fine to use some other ids for now, we can always change them later if this causes a problem. -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Re: wine/ tools/winewrap.c tools/winegcc.c include ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > What about adding it to the portability lib? I can do the patch > if you want... I'm not sure about that; it would be somewhat cleaner, but OTOH I'm not sure I like the idea of adding DOS functions in the portability layer... -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003

Re: wine/ tools/winewrap.c tools/winegcc.c include ...

by Dimitrie O. Paun

On March 31, 2003 10:20 pm, Alexandre Julliard wrote: > I'm not sure about that; it would be somewhat cleaner, but OTOH I'm > not sure I like the idea of adding DOS functions in the portability > layer... However, if we are to depend on winegcc/winewrap, we need to be able to compile it anyway, no? And since it has a well defined semantics (that's much more commonly available than the fork/exec), it's not necessarily a bad addition. I mean, there's nothing conceptually wrong with spawn/CreateProcess/etc. vs. fork+exec. However, on system that are spawn-based, it's *so* difficult to simulate fork+exec, and for no good reason, if all you need is to spawn another program. So it seems to me having spawn in a portability layer may actually be a good thing, since it's more semantically loaded than fork, and thus easier to simulate on a large range of systems. -- Dimi.

April 1, 2003

Re: wine/ tools/winewrap.c tools/winegcc.c include ...

by Dimitrie O. Paun

On March 31, 2003 07:12 pm, Alexandre Julliard wrote: > Log message: > Use _spawnvp to replace fork for non-Unix platforms. What about adding it to the portability lib? I can do the patch if you want... -- Dimi.

April 1, 2003

Re: Problem with debugging: XIO: fatal IO error 0 (Success) on X server ":0.0"

by Alexandre Julliard

Juraj Hercek <juraj(a)syncad.com> writes: > I have troubles with debugging winelib applications. > This is what makes me unhappy: > --- > $ gdb wine > (gdb) r notepad > Starting program: /usr/local/bin/wine notepad > XIO: fatal IO error 0 (Success) on X server ":0.0" > after 187 requests (187 known processed) with 0 events remaining. That's because of the errno problems with the new glibc. Working on it... -- Alexandre Julliard julliard(a)winehq.com

April 1, 2003