June 2005 - Wine-Devel - list.winehq.org

Re: dlls/ntdll/cdrom.c breakage

by Gerald Pfeifer

On Thu, 30 Jun 2005, Dmitry Timoshkov wrote: >> cdrom.c: In function `CDROM_ScsiPassThroughDirect': >> drom.c:1423: error: invalid application of `sizeof' to an incomplete type >> cdrom.c: In function `CDROM_ScsiPassThrough': >> cdrom.c:1543: error: invalid application of `sizeof' to an incomplete type > I don't see how it worked before then, you need to investigate why > '#ifdef SENSEBUFLEN' case doesn't work for you. I checked, and there is no occurrence of SENSEBUFLEN in /usr/include on a SUSE 9.2 machine nor on FreeBSD nor in the entire Wine source tree. How shall we proceed on this one? Gerald

June 30, 2005

Re: unixfs registered by default now in cvs

by Michael Jung

On Thursday 30 June 2005 21:21, Brian Vincent wrote: > Does this mean there's no longer a need to map a Z: drive to /? You still can only access the parts of the filesystem, which are accessible by a wine drive. You will see the complete unix directory structure, but you will only be able to select files, which are accessible by wine. The unix directories, which are not accessible, are much like the MyComputer folder in that they don't map to a windows filesystem location. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

June 30, 2005

Bug in dlls/comctl32/comctl32undoc.c

by Sascha Cunz

Hi, playing around a bit with wine, i found a thing that is obviously a bug. In lines 1944 and 1977 of dlls/comctl32/comctl32undoc.c the value "0x7FFF" is used to check for the boundary of a 32 bit integer. However, there should be used MAX_INT instead. By the way: Looking at current MSDN, DPA and DSA looks rather documented than "undoc" :-) Regards Sascha P.S.: Please CC me on answers as i'm not subscribed here.

June 30, 2005

Re: dlls/ntdll/cdrom.c breakage

by Gerald Pfeifer

On Thu, 30 Jun 2005, Dmitry Timoshkov wrote: >> Alexandre, please find below another patch which does not fix this either, >> but gets rid of some unused variable warnings. >> ChangeLog: >> Avoid unused variable warnings in CDROM_ScsiPassThroughDir() and >> CDROM_ScsiPassThrough(). > This means that HAVE_SCSIREQ_T_CMD is not defined for you, i.e. scsireq_t > has not been detected. Very likely this is caused by a wrong/missing header > includes in the configure.ac test, please fix it, it's easy enough. I found that FreeBSD does not have this type defined anywhere, so I hope Alexandre will take my patch. Gerald

June 30, 2005

Re: Wine avitools/aviplay fails with CO_E_NOTINITIALIZED for any AVI file

by Alex Villacís Lasso

>It worked in the past. When pclsidHandler is set to NULL it performs >a registry lookup as the native version does it. If these registry >entries are missing it has a problem and could perhaps return the >mentioned error - don't know as I have never tested it. > >In the past these informations were part of the default registry of >wine but with the addition of the self-registration of many libraries >this has been removed. Don't ask me how to get the library to >register itself - guess it has to do with regsrv32.exe, but I am not >sure. I am already too long out of the substance. > > Based on a certain verification in the source code, I made aviinfo to work by adding the following to the registry: [Software\\Classes\\CLSID\\{00020000-0000-0000-C000-000000000046}\\InProcServer32] 1110571609 @="avifil32.dll" "LoadWithoutCOM"=dword:00000000 As far as I can see, the key "LoadWithoutCOM" only needs to exist; it does not need to be set to any particular value. The aviplay program has yet to work because the 128x128 AVI file I was using for the test in one machine (apparently) mandates a 128x128 screen resolution which is (yet) unsupported by my X configuration, and the ideal 640x480 test AVI is on the other (currently inaccessible) machine: trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 128: 320x240x16 @60 Hz (XRandR) trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 129: 360x200x16 @85 Hz (XRandR) trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 130: 320x200x16 @85 Hz (XRandR) trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 131: 320x175x16 @85 Hz (XRandR) trace:x11settings:X11DRV_Settings_CreateDriver Setting up display settings for DDRAW (XRandR) fixme:avifile:AVIFileInit (): stub! [Stream 0: vids.cvid, cineapk.avi v�eo #0] trace:x11settings:X11DRV_ChangeDisplaySettingsExW ((null),0x707bf768,(nil),0x00000004,(nil)) trace:x11settings:X11DRV_ChangeDisplaySettingsExW flags=FULLSCREEN trace:x11settings:X11DRV_ChangeDisplaySettingsExW DM_fields=BITSPERPEL,PELSWIDTH,PELSHEIGHT trace:x11settings:X11DRV_ChangeDisplaySettingsExW width=128 height=128 bpp=24 freq=1887172668 (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsExW No matching mode found! (XRandR) ddraw.SetDisplayMode: 0x88760078 (change resolution!) But this raises the following questions: * Why is not avifil32.dll adding this key on registration by regsvr32? (I could submit a patch to do it, but see next questions) * Is this the correct usage of avifil32.dll? The loading of this dll occurs via SHCoCreateInstance in shell32/shellole.c, and the comment on the usage of the LoadWithoutCOM key goes like this: //* if a special registry key is set, we load a shell extension without help of OLE32 *// bLoadWithoutCOM = (ERROR_SUCCESS == SHQueryValueExW(hKey, sLoadWithoutCOM, 0, 0, 0, 0)); Is this the correct (or even supported) usage for avifil32.dll? This LoadWithoutCOM kludge does not appear anywhere else in my registry, and it looks like it is intended for shell extensions only. What is the meaning of "shell extension" here? Does avifil32.dll qualify? (I think not, because avifil32 is concerned with AVI file handling, not with user interface. However, I might be wrong.) The last thing I want is to submit a patch, only to be rejected because it attempts to use a DLL in a way not intended by its design. So, is this approach correct (adding LoadWithoutCOM as part or regsvr32 initialization of avifil32.dll), or should an apartment actually be initialized in full COM style? Do you know if LoadWithoutCOM is used anywhere else in Wine? Alex Villacís Lasso

June 30, 2005

Re: unixfs registered by default now in cvs

by Brian Vincent

On 6/30/05, Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > With the current CVS version, the unixfs shell namespace extension is now > registered by default at the desktop. So if you do a 'regsvr32 shell32' you Does this mean there's no longer a need to map a Z: drive to /? -Brian

June 30, 2005

Re: Anybody looking for a pet Wine project?

by Jacek Caban

I forgot to attach hh.exe... #include <windows.h> typedef int WINAPI DOWINMAIN(HMODULE hMod, LPSTR cmdline); int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR cmdline, int cmdshow) { HMODULE hModule; DOWINMAIN *doWinMain; hModule = LoadLibrary("hhctrl.ocx"); doWinMain = GetProcAddress(hModule, "doWinMain"); return doWinMain(hInst, cmdline); }

June 30, 2005

Wine avitools/aviplay fails with CO_E_NOTINITIALIZED for any AVI file

by Alex Villacís Lasso

I recently downloaded Wine-20050628 (self contained install with fake Windows drive) and tried to use the aviplay program in programs/avitools directory. However, this program fails with this odd error trace: [bash$] WINEDEBUG=shell,ole wine ~/temp/wine/wine-20050628-patch/programs/aviplay.exe.so blur24.avi ... trace:shell:SIC_IconAppend L"c:\\windows\\system\\shell32.dll" 37 0x1126 0x112e trace:shell:SHAlloc 20 bytes at 0x65f43068 trace:shell:SIC_IconAppend L"c:\\windows\\system\\shell32.dll" -38 0x1126 0x112e trace:shell:SHAlloc 20 bytes at 0x65f430d0 trace:shell:SIC_Initialize hIconSmall=0x65f2f5e0 hIconBig=0x65f31190 fixme:avifile:AVIFileInit (): stub! trace:shell:HCR_RegOpenClassIDKey CLSID\{00020020-0000-0000-c000-000000000046} trace:shell:HCR_GetClassNameA -- trace:shell:HCR_RegOpenClassIDKey CLSID\{00020000-0000-0000-c000-000000000046} trace:shell:HCR_GetClassNameA -- Microsoft AVI Files trace:shell:SHCoCreateInstance ((nil), {00020000-0000-0000-c000-000000000046} (Microsoft AVI Files),unk:(nil), {00020020-0000-0000-c000-000000000046} (unknown),0x65cbf8fc) trace:shell:SHQueryValueExW (hkey=0x64,(null),(nil),(nil),0x65cbf338,0x65cbf330=520) trace:shell:SHQueryValueExW (hkey=0x64,L"LoadWithoutCOM",(nil),(nil),(nil),(nil)=0) trace:shell:PathFindFileNameW (L"avifil32.dll") trace:shell:SHCoCreateInstance WithoutCom=0 FromShell=0 trace:shell:HCR_RegOpenClassIDKey CLSID\{00020020-0000-0000-c000-000000000046} trace:shell:HCR_GetClassNameA -- trace:shell:HCR_RegOpenClassIDKey CLSID\{00020000-0000-0000-c000-000000000046} trace:shell:HCR_GetClassNameA -- Microsoft AVI Files err:shell:SHCoCreateInstance failed (0x800401f0) to create CLSID: {00020000-0000-0000-c000-000000000046} (Microsoft AVI Files) IID: {00020020-0000-0000-c000-000000000046} (unknown) err:shell:SHCoCreateInstance class not found in registry trace:shell:SHCoCreateInstance -- instance: (nil) AVIFileOpen: 0x800401f0 I looked up in the include files, and the value of 0x800410f0 is CO_E_NOTINITIALIZED. This is confirmed by a check in the source code that indicates that the apartment was not initialized (please correct me if I get the terminology wrong). The code for aviplay and aviinfo does not attempt to initialize any apartment prior to calling AVIFileOpen with /pclsidHandler/ set to NULL. I looked up in MSDN, and the documentation for AVIFileOpen does not suggest (to me at least), that an apartment should be initialized by the caller. This seems odd, since this means that the program should never have worked in the first place, yet the comments in the source suggest that it worked at least once. Are these avitools maintained? If so, does this result from a misconfiguration (the same one in two different machines so far), or from a genuine incomplete implementation? I would like to hear any comment on this. The original purpose of messing with aviplay was to test whether the Indeo video codecs are actually usable after being installed under Wine, but this problems affects even files not encoded with Indeo. Alex Villacís Lasso

June 30, 2005

Re: MSHTML: fix blank.htm resources

by Jacek Caban

Alexandre Julliard wrote: >That's a feature ;-) We can't support loading builtins as datafiles, >so the idea is that it's more likely that the app will be happy with >loading the native as datafile than loading the builtin in normal >mode. It does make the behavior a bit surprising I agree. > > > Good to know that Wine doesn't have such bug in so important place:-) Maybe it would be better to point it out somewhere in the documentation so that people like me won't have to cover such things themselves. Thanks, Jacek

June 30, 2005

Re: Anybody looking for a pet Wine project?

by Jacek Caban

Hello. I think it will be great to have it done. I'd like to point out one thing for the way to implement it: the most important is to have it working with native shdocvw.dll and mshtml.dll. It won't work with built in in the current state of them, but it will be fixed soon and I believe it can be in CVS even if it doesn't work without these dlls. While implementing then we shouldn't pay too much attention to get it working with Mozilla ActiveX Control - it will never work perfectly and I hope to get rid of its dependency soon. Of course you may do it working, but, as my tests show, it's far from compatible with MS. Also, we need to use itss.dll, which is impossible with Mozilla ActiveX (I'm not sure if Mozilla has support for chm protocol, but even if so it's worse to use it). About implementing hh.exe... it seams to be pretty easy. Attached is (not tested) implementation:-) Another related idea is, as I have spoken with Mike on irc, to use html help in winecfg. It looks like a nice way to have a complex and integrated help. This would mean that we need to implement the chm compiler. To do so we may use chmlib: http://66.93.236.84/~jedwin/projects/chmlib/ that Mike used in itss to decompress chm. As a conclusion: it would be really good to have this working in Wine. It uses most of IE related API (I didn't mension URLMoniker here, which also needs some work) and getting it to work out of box will be a great test for Wine. Thanks, Jacek

June 30, 2005