January 2004 - Wine-devel - list.winehq.org

Re: bin2res - Make adding resources work on Windows.
by Dmitry Timoshkov 18 Jan '04

18 Jan '04

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > I dont know if anyone else has tried this but when I try to add > resources to a *.rc I get a error. This patch fixes it. What kind of error do you get? I just tried to change an .rc and to rebuild resources of commdlg under cygwin and I don't see any problem with it. -- Dmitry.

2 2

Re: ntdll / kernel32 #39-2
by Dmitry Timoshkov 18 Jan '04

18 Jan '04

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > +DWORD WINAPI GetFullPathNameW( LPCWSTR name, DWORD len, LPWSTR buffer, > + LPWSTR *lastpart ) > +{ > + LPWSTR dst = HeapAlloc(GetProcessHeap(), 0, len * sizeof(buffer)); > + DWORD ret; > + > + if (!dst) return 0; > + ret = RtlGetFullPathName_U(name, len * sizeof(WCHAR), dst, lastpart) / sizeof(WCHAR); I don't quite understand the above bit of code: 1. HeapAlloc(GetProcessHeap(), 0, len * sizeof(buffer)) when buffer is a pointer 2. Why you don't pass buffer directly to RtlGetFullPathName_U without allocating an intermediate storage. -- Dmitry.

2 1

Alsa 1.0 patch for audio.c
by Brett I. Holcomb 18 Jan '04

18 Jan '04

In November Sylvain Petreolle posted a patch to audio.c to make it work with the new Alsa 1.0 version. What is the license on that patch? I ask because I'd like to pass it on to the winex-devel list so they can include it. Is it possible to send it on? If not that's fine - I want to check first. Thanks.

2 1

Debugger doc pages
by Jason Edmeades 18 Jan '04

18 Jan '04

Is it something about my machine but when I go to the online debugger docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can see absolutely nothing in the text boxes. I can highlight the text and it appears to be in a minute font, and cut+paste into an editor shows me the text is there, its just too small to be visible. I tried with mozilla and IE (both from a Windows machine). Jason

4 3

Re: Need help debugging ...
by Jason Edmeades 18 Jan '04

18 Jan '04

Hope you dont mind, I was bored and its a small download (DK1). The disassembly of the failure shows we have written to eax, and info regs shows eax of 0x00. dis 0x4e4a20 shows the routine where the return value is set up in eax, and some debugging shows the initial problem is a path problem. The routine parses the input path which inder windows is c:\path\to\KEEPER95.exe and under wine is KEEPER95. It searches backwards for the last backslash and returns a pointer to the backslash or 0x00. If 0x00, the trap occurs... Now the question is where does the full path come from. Jason

8 16

Re: Add iccvid.spec to winapi_check
by Hans Leidekker 17 Jan '04

17 Jan '04

On Thursday 15 January 2004 16:07, Vincent Béron wrote: > Changelog: > Yet another new spec file added to winapi_check/modules.dat, this time > iccvid.spec. After DLL separation is complete, adding these will no longer be necessary, right? -Hans

3 4

I'm off to Cuba!
by Dimitrie O. Paun 17 Jan '04

17 Jan '04

Si señor, I'm off for a week to Varadero, Cuba! Given the terrible temperatures we had here lately (-39C with the windchill), I am happy beyond words to bask in the sun for a week. I hope it's going to be sweet, but I'll be off the web until next Sunday. Until then, hasta la vista amigos! :) -- Dimi.

1 0

Re: PATCH: tools/winewrapper and memory limits
by Marcus Meissner 17 Jan '04

17 Jan '04

On Sun, Jan 18, 2004 at 02:11:22AM +0100, Gerald Pfeifer wrote: > This would have saved me a _lot_ of time late last year. With a > memory limit set too low, I would simply get an Abort, both when > running Wine itself and `ldd wine-binary`. :-( > > This is not really FreeBSD-specific, for Marcus Meissner encountered the > problem on SUSE Linux as well; feel free to remove the first condition! This does not really help, since winewrapper is only used for in-source-tree startup. Once installed, 'wine' is no longer this shellscript, but an ELF binary. Ciao, Marcus

2 1

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 17 Jan '04

17 Jan '04

Wow, lots of updates, and rather than reply to each let me try to summarize. >> The one thing I couldnt answer is how the game 'gets' the command line. >int WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ); Perhaps this way? No, I noticed the difference between the exe hdrs, (console vs gui) and I ran some tests on this, and the value in lpCmdLine seemed to be just the parms and not the "command line" / executable name. Thats why I then went on to try GetCommandLine and spotted that issue. Nice idea though, thanks >Ok, that here is exactly the problem (dlls/kernel/environ.c), it's explained in the remark of the func: >GetCommandLineA (KERNEL32.@) >* * WARNING: there's a Windows incompatibility lurking here ! >* Win32s always includes the full path of the program file, >* whereas Windows NT only returns the full file path plus arguments >* in case the program has been started with a full path. >* Win9x seems to have inherited NT behaviour. I read that as saying Win32s just provides the path and probably exe name and Winnt provides the full path, exe and parms. You may be correct, I didnt investigate this further. >> With some experimentation with a GUI pgm I think I stumbled upon the / >> an answer: > Bug#1 - GetCommandLine() returns a full path on Windows but no path on Wine Doh. >Well this should definately be fixed anyway (with a regression test), and it does sound a lot like the problem doesn't it? >I expect we use this API (or similar) to set the parameters to WinMain Yes, but I didnt see any evidence it was being called. I may have missed it.. However I think this is also a red herring... > * Note that both Start Menu Execute and Explorer start programs with > * fully specified quoted app file paths, which is why probably the only case > * where you'll see single file names is in case of direct launch > * via CreateProcess or WinExec. This may be the real issue - I was running it from within msdev.exe which works, but launching it from the command line does trap the same way. "Windbg keeper95.exe" traps on run, but windbg, ctrl+e (open exe) doesnt, and I think thats because the file dialog returns fully qualified paths (at a guess). >I wonder if when a program is invoked directly from the wine loader app we should pretend >it's been run from Explorer and pass it the full path. Alexandre, would that be an acceptable >solution (subject to more thorough testing of course). I'd be worried this may cause more problems than it solves. This is an interesting one in that wine *does* correctly emulate windows behaviour, but the app is broken to only expect a full path. Aside from an app specific option (perhaps we could add in app specific config options into a central compatibility ini file), I think the only way to capture this is to document in eg. the appDB. >"Some debugging" is a bit vague but I'll let you off that ;) I guess I just need to get better at reading disassemblies. It certainly helps as I frequently drop down to assembler when things get confusing (my 'real' job involves lots of debugging!). I wish I was better with eg. gdb syntax as I really am mostly a Windows person so far (Boo Hiss...)! Jason

3 2

Re: winecfg: a patch to review
by Ivan Leo Murray-Smith 17 Jan '04

17 Jan '04

> Windows actually does have a few settings like this (Well, XP does) Windows server 2003 and longhorn have the same functionality, and blackcomb probably has it too. Ivan.

1 0