September 2002 - Wine-Devel

Re: ALSA 0.9 sound problems

by Marco Pietrobono

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, sorry for the delay in my answer, but my mail server was down... I've worked on the ALSA 0.9 driver for wine, and I know it has problems. I was planning to restart to work on it in the past weeks but, due to my job, I haven't been able to do it. Right now, I'm going on vacation and I'll be back 4 weeks from now. I think I'll we able to restart coding around the first week of October. Before then, I'm not sure I'll be able to check my e-mail since I'll be "on the road" (literally :-) I'll be travelling along the old Route 66 during these weeks... :-) Feel free to try by yourself in the mean time. The code in itself is not so hard to understand. It is more difficut to get a grip on how the windows applications are using the DSOUND interface. On Sun, 1 Sep 2002, TJ wrote: [snip] > maybe compare how snd-pcm-oss streams the sound to alsa, with how > winealsa.drv streams the sound to alsa. since it seems snd-pcm-oss does > a better job of it =) this is how it has been done... :) but, there are still few issues that need to be worked out, mainly because the oss layer is really a kernel thing, so it has access to the internals of the alsa driver, while we are accessing the driver from its published interface. basically, we need a way to get feedback from the kernel driver about how much portion of the enqueued sound has already been played. And we need to check how to relate the written bytes and played bytes that the Windows application wants to track through the DSOUND_GetPosition() call. The current way to evaluate those values from the "current position" we have got from the alsalib (which BTW is really an hack, since we are using an internal variable of the library through an internal function which IIRC is not part of the public API of the alsalib. I would like to test something different, like the secondary buffer approach, but it isn't so simple. BTW, we have been contacted by one of the ALSA developer who was willing to work on the driver, so I hope to be able to do something with his help when I'll be back. > -TJ bye, /pietrobo - -- Stud. Marco Pietrobono | Murphy's Law: if something could v. del Calice, 39 - 00178 ROMA | go wrong, it does. Tel. +39.6.7186329 0339.7410893 | Legge di Murphy: se qualcosa può http://www.pietrobo.com | andar male, lo farà. - ------------------------------------------------------------------------ Strange game. The only winning move is not to play. What about a nice play of chess ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9c2suJdpOg6vRQxoRAnb6AJ9L0t21KaBHTx1UaL9MF3wpsWmpUACfXfX9 OkJypV310T1O2zci6q308Do= =MhXH -----END PGP SIGNATURE-----

Sept. 2, 2002

Creating ocx

by Fabian Cenedese

Hi I have a problem with an ocx (not with WineDbg this time :). To create it I do: CreateControl(GetClsid(), lpszWindowName, dwStyle, rect, pParentWnd, nID,pPersist, bStorage, bstrLicKey); which works fine in windows (NT4), but in Wine-20020804 I get the following: First chance exception: e06d7363 in 32-bit code (0x400d5ee5). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:400d5ee5 ESP:405c4e18 EBP:405c4e70 EFLAGS:00000246( - 00 I Z- -P1 ) EAX:405c4e20 EBX:4010ca04 ECX:00000000 EDX:405c4e34 ESI:405c4f4c EDI:00000000 Stack dump: 0x405c4e18 (_end+0x265cf4): 4010ca04 400ca2f2 e06d7363 00000001 0x405c4e28 (_end+0x265d04): 00000000 400d5e70 00000003 19930520 0x405c4e38 (_end+0x265d14): 405c4f84 5f4bb5d8 405c4ecc 400fbc9c 0x405c4e48 (_end+0x265d24): 405c4e74 00000400 405c4f58 405c4e80 0x405c4e58 (_end+0x265d34): 4010ca04 400da28a 00000002 40123a68 0x405c4e68 (_end+0x265d44): 00000058 40129d48 405c4e90 400ca303 0x405c4e78 (_end+0x265d54): 0011: sel=008f base=401225c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x400d5ee5 (RaiseException+0x75(code=0xe06d7363, flags=0x1, nbargs=0x3, args=0x405c4f4c) [except.c:81] in libntdll.dll.so) (ebp=405c4e70) 1 0x400ca303 (call_stdcall_function+0xc3(func=0x400d5e70, nb_args=0x4, args=0x405c4f20) [relay386.c:327] in libntdll.dll.so) (ebp=405c4e90) 2 0x400ca6e8 (RELAY_CallFrom32+0x148(ret_addr=0x7800ac4e) [relay386.c:400] in libntdll.dll.so) (ebp=405c4f14) 3 0x4076fed5 (KERNEL32.DLL.TryEnterCriticalSection+0x2b59 in kernel32.dll.so) (ebp=405c4f58) 4 0x5f47d5b1 (MFC42.DLL.1269+0x4d in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c4f7c) 5 0x5f48ceab (MFC42.DLL.2464+0x11c in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c5004) 6 0x5f423445 (MFC42.DLL.4035+0x51 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c502c) 7 0x5f42348d (MFC42.DLL.6095+0x43 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c5054) 8 0x5f423520 (MFC42.DLL.5719+0x28 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c5088) 9 0x5f42375d (MFC42.DLL.6198+0x14 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c50f0) 10 0x5f421996 (MFC42.DLL.6621+0x86 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c5148) 11 0x5f42168b (MFC42.DLL.6623+0x3f in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c5184) 12 0x5f421647 (MFC42.DLL.2135+0x59 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405c51d8) 13 0x3001e1ad (CIXOutWinView::Create+0x43(lpszWindowName=0x406cb3f0, dwStyle=0x50300000, rect=0x405c5244, pParentWnd=0x41568c60, nID=0x1320, ExtStyle=0x200, pPersist=0x0, bStorage=0x0, bstrLicKey=0x0) [N:\IMD\Imex\Src\IXOutWin.cpp:167] in C:\IMD\BIN\IMEX.DLL) (ebp=405c520c) (here is the above mentioned CreateControl) 0x400d5ee5 (RaiseException+0x75 [except.c:81] in libntdll.dll.so): leal 0xffffffa8(%ebp),%esp 81 RtlRaiseException( &record ); It finds the .ocx so that shouldn't be a problem. The registry should be correct too as other ocx's I have work fine, all installed with the same setup. This is also the reason why I believe it's something inside the ocx code. The exception code e06d7363 means float inexact result or so, but I never used float or double or any 64 bit integer. The OnCreate and OnFontChanged of the ocx are called and left successfully. I traced it down to this (shortly after OnFontChanged is left, maybe some painting done): 08153fd8:Call kernel32.lstrlenA(405c5062 "\016") ret=5f418414 08153fd8:Ret kernel32.lstrlenA() retval=00000001 ret=5f418414 08153fd8:Call kernel32.lstrlenA(406cb3f0 "") ret=5f4184ce 08153fd8:Ret kernel32.lstrlenA() retval=00000000 ret=5f4184ce 08153fd8:Call kernel32.MultiByteToWideChar(00000000,00000000,406cb3f0 "",ffffffff,405c4f88,00000001) ret=5f4184f9 08153fd8:Ret kernel32.MultiByteToWideChar() retval=00000001 ret=5f4184f9 08153fd8:Call kernel32.GetProcAddress(65340000,00000002) ret=5f405724 08153fd8:Ret kernel32.GetProcAddress() retval=65341408 ret=5f405724 08153fd8:Call kernel32.IsBadReadPtr(405c4f98,00000020) ret=42622bce 08153fd8:Ret kernel32.IsBadReadPtr() retval=00000000 ret=42622bce 08153fd8:Call kernel32.IsBadReadPtr(405c4fd8,00000004) ret=42622bce 08153fd8:Ret kernel32.IsBadReadPtr() retval=00000000 ret=42622bce 08153fd8:Call ntdll.RtlSizeHeap(40360000,00000000,403c0738) ret=65f019c3 trace:heap:RtlSizeHeap (40360000,00000002,403c0738): returning 00000020 08153fd8:Ret ntdll.RtlSizeHeap() retval=00000020 ret=65f019c3 08153fd8:Call kernel32.RaiseException(e06d7363,00000001,00000003,405c4f4c) ret=7800ac4e 65340000 is the handle for the OLEAUT32.DLL, function 2 seems to be SysAllocString but it doesn't seem to get there (at least I never see my message in the log file).. Any ideas how I can find out what goes wrong (inside the MFC42.dll)? Thanks Fabi

Sept. 2, 2002

Re: SHLWAPI IQueryAssociations helpers

by Jürgen Schmied

> This patch implements the Assoc* functions for SHLWAPI. We need to > decide whether to duplicate or share the code for the underlying COM > object though (i.e. can I include the c file from the shell dir?). Sharing code is never a good idea. Usually windows implements things on one place and we should do so too. The only reason for some code duplication between shlwapi and shell32 is ms moved some functionality from shell32 to shlwapi over time. All the assoc-stuff belongs to shlwapi now. Shell32 uses only this services. juergen --- juergen.schmied(a)debitel.net

Sept. 2, 2002

Re: Opinions about univesal printer driver

by Huw D M Davies

On Mon, Sep 02, 2002 at 02:31:38AM +0200, Ilja Kamps wrote: > On Mon, Sep 02, 2002 at 02:17:41AM +0200, m.kostrzewa(a)pentacomp.com.pl wrote: > > I'm trying to imagine a method for using windows printer drivers under > > linux. As far as I know, from gdi's point of view it works like: > > LoadLibrary(driver) (drv appears to be a dll), > > some of 24 DDI functions which every printer driver should contain, > > Initialization = Enable, Control, next goes drawing functions like Output, > > Pixel. It doesn't have to access paralell ports - it can write to file > > (when printing under Windows you have this little checkbox, and gdi > > initializes driver telling this filename I think). Content of this file can > > be directly sent to port in Linux's way. I know that's not that simple, but > > I'm very interested in your opinions: what do you think about it having > > experience in dlling under linux :-) ? I know that wine doesn't run > > drivers, but it can run win dlls. Is it possible at all? Or this is just a > > linux-supports-every-printer dream? Perhaps someone tried this already? > > > Well, Wine once supported Windows printer drivers, (I belive the support got > broken in early 2001), but based on that you should be able to resurrect support > without too much trouble. There's some support for 16 bit printer drivers (note the drivers for win9x are 16 bit). The code is in dlls/gdi/win16drv/ but as you say this may well be broken at the moment. Huw. -- Huw Davies huw(a)codeweavers.com

Sept. 2, 2002

Re: Heap overruns

by Shachar Shemesh

Marcus Meissner wrote: >Such a thing is not really implemented yet. > Does anyone have any objections to me having a go at implementing it (perhaps at some time in the future)? >There is a freeware tool called 'valgrind' which might be instrumentable, >but I do not think it can cope with wines very own memory management yet. > It has a whole bunch of other limitations that do not look promising. Bad replacing stacks, bad own memory managment support (i.e. - we have to teach it how Windows allocates memory), no good support of threads. It seems to me like there is a LOT of porting work to do. My suggestion, while nowhere near as powerful as that, is simple and with low overhead. >You could add assert(HeapValidate(heap,0,NULL))); around critical pieces >of code, to call the heap checking more often. (replace heap by >GetProcessHeap(), or whatever heap you use.) > I have found the specific cause of my corruption. I am talking about a "next time" tool, as well as an auditing tool (the most dangarous overruns are those that do not crash the program). I was also not asking anyone to implement this. Just asking whether anything like that was already implemented, and whether there was any objections to me having a go at implementing it if not. Shachar

Sept. 2, 2002

Re: Heap overruns

by Marcus Meissner

> Thanks, but this is not what I meant. > > Currently, when a buffer overruns, the free pointers right after get > corrupted, and when the next piece of block is allocated, the machine > will crash. This will tell me approximetly where the buffer overrun, but > is, generally speaking, too late. Enabling the debug messages detects > the error at the same place (i.e. - too late). > > What I am talking about is a compile time (or run time, no reason why > not) option that will add "hot zone" areas before and after each heap > allocated buffer. These zones should be: > A. Large enough so that the overrun doesn't reach the heap managment > structures themselves. This means that the program can keep on running > despite having the buffer overflow. > B. Identifiable, so that we know if a buffer has overwritten it. > > Whenever you free a buffer, you check the hot zones. If they have > changed, the buffer you are freeing now has been overwritten. This gives > an excellent debugging tool, as it points right at the offending code. Such a thing is not really implemented yet. There is a freeware tool called 'valgrind' which might be instrumentable, but I do not think it can cope with wines very own memory management yet. You could add assert(HeapValidate(heap,0,NULL))); around critical pieces of code, to call the heap checking more often. (replace heap by GetProcessHeap(), or whatever heap you use.) Additionaly you could careful reread and reaudit your code (even in diff form) ;) Ciao, Marcus

Sept. 2, 2002

Re: Heap overruns

by Shachar Shemesh

Joerg Mayer wrote: >On Mon, Sep 02, 2002 at 12:22:44AM +0300, Shachar Shemesh wrote: >[many lines of history deleted] > > >>Implementing my suggested system will: >> >> > >Maybe there's another solution: Someone with very intricate knowledge >of wine and the x86 processor could get valgrind to work - this would >provide a very powerful tool. > > Ciao > Jörg > Just my opinion, of course, but this would require WAY more work than implementing my suggestion. I am also not sure how valgrind does with heaps, where the entire memory does belong to the application, but a given memory location is accessed via a pointer that was supposed to be used on another section. I know that commercial Win32 tools (such as BoundsChecker, by NuMega) do that using profie compiling - i.e. - they do exactly what I suggested in the previous mail. As usual, the best approach would probably be doing both. Shachar

Sept. 2, 2002

Re: Opinions about univesal printer driver

by Ilja Kamps

On Mon, Sep 02, 2002 at 02:17:41AM +0200, m.kostrzewa(a)pentacomp.com.pl wrote: > I'm trying to imagine a method for using windows printer drivers under > linux. As far as I know, from gdi's point of view it works like: > LoadLibrary(driver) (drv appears to be a dll), > some of 24 DDI functions which every printer driver should contain, > Initialization = Enable, Control, next goes drawing functions like Output, > Pixel. It doesn't have to access paralell ports - it can write to file > (when printing under Windows you have this little checkbox, and gdi > initializes driver telling this filename I think). Content of this file can > be directly sent to port in Linux's way. I know that's not that simple, but > I'm very interested in your opinions: what do you think about it having > experience in dlling under linux :-) ? I know that wine doesn't run > drivers, but it can run win dlls. Is it possible at all? Or this is just a > linux-supports-every-printer dream? Perhaps someone tried this already? > Well, Wine once supported Windows printer drivers, (I belive the support got broken in early 2001), but based on that you should be able to resurrect support without too much trouble.

Sept. 2, 2002

Opinions about univesal printer driver

by m.kostrzewa＠pentacomp.com.pl

Greetings to all Wine community! I've been wondering if this is the right place to post it, I belive yes, please forgive me if not :) I'm trying to imagine a method for using windows printer drivers under linux. As far as I know, from gdi's point of view it works like: LoadLibrary(driver) (drv appears to be a dll), some of 24 DDI functions which every printer driver should contain, Initialization = Enable, Control, next goes drawing functions like Output, Pixel. It doesn't have to access paralell ports - it can write to file (when printing under Windows you have this little checkbox, and gdi initializes driver telling this filename I think). Content of this file can be directly sent to port in Linux's way. I know that's not that simple, but I'm very interested in your opinions: what do you think about it having experience in dlling under linux :-) ? I know that wine doesn't run drivers, but it can run win dlls. Is it possible at all? Or this is just a linux-supports-every-printer dream? Perhaps someone tried this already? best regards, Michal Kostrzewa

Sept. 2, 2002

Re: Heap overruns

by Joerg Mayer

On Mon, Sep 02, 2002 at 12:22:44AM +0300, Shachar Shemesh wrote: [many lines of history deleted] > Implementing my suggested system will: Maybe there's another solution: Someone with very intricate knowledge of wine and the x86 processor could get valgrind to work - this would provide a very powerful tool. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Sept. 1, 2002