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

Re: wineserver epoll

by Alexandre Julliard

Shachar Shemesh <wine-patches(a)shemesh.biz> writes: > After much talk, the patch seems ready for commit. Since there are many > systems with slightly older glibc that have the header but do not have > the implementation in glibc, or that have a stub implementation that is > guaranteed to fail, we are calling the kernel functions directly. This > also allows compiling on older systems than the code actually ships to. > > Accordingly, the autoconf checks for epoll_create in glibc were dropped. That's wrong; if the libc function exists you should use it, direct system calls should only be used as a fallback. And when using system calls you must not depend on the libc header, you have to define the structures yourself. -- Alexandre Julliard julliard(a)winehq.org

Aug. 29, 2004

RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars

by Steven Edwards

Hi Jens, --- Jens Collin <jens.collin(a)lakhei.com> wrote: > Is there anything wrong with this patch? I can't see my changes taken > place in CVS. > Let me know and I'll fix 'em. I looks like it might be because of indenting tabs/spaces and C++ style comments. This PWSTR res = out; PCWSTR cmd; LPVOID pv; + WCHAR tmpBuffer[1024]; + PWSTR tmpB = tmpBuffer; + WCHAR tmpEnvBuff[MAX_PATH]; + WCHAR* tmpE = tmpEnvBuff; + DWORD envRet; and this + // Make sure that we have at least one more %. Thanks Steven _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

Aug. 29, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Steven Edwards

Hi, --- Filip Navara <xnavara(a)volny.cz> wrote: > Wine DLLs. It produced bunch of FIXMEs, but generated the type > library > in the end. The result is attached. Compared to the type library > generated using the same executable with Windows DLL only two bytes > differ. Is there some type library dump program that can be used to > find > out what are the differences or am I left alone and should I try to > find > out the actual differences other way? After a quick google search. I dont know if this will give you all the information you need but it does have a sample program that can do simple dumping of typelibs. http://www.microsoft.com/msj/0399/comtype/comtype.aspx Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Aug. 29, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Filip Navara

Huw D M Davies wrote: >You're right, an MSFT stdole32 might work fine - I guess we should at >least try it. So for fun I've attached the program we used to >generate CrossOver's stdole32.tlb (Actually you need to take the >generated file and wrap it up in a resource only dll, but that's a >detail). Since it was designed to be compiled with MSVC, it uses the >L"" construct for olestrings - you can hack around this by compiling >with -fshort-wchar for now. > > I tried to change CreateTypeLib to CreateTypeLib2 and running it with Wine DLLs. It produced bunch of FIXMEs, but generated the type library in the end. The result is attached. Compared to the type library generated using the same executable with Windows DLL only two bytes differ. Is there some type library dump program that can be used to find out what are the differences or am I left alone and should I try to find out the actual differences other way? - Filip fixme:typelib2:ctl2_encode_typedesc Array vartype, hacking badly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc Unrecognized type 12. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (00257CD8,0,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610612736,00000000,0022FD80,1,1,4,2,0,0,0,{25},1} fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (00257CD8,0,L"QueryInterface",3), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (00257CD8,1,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610612737,00000000,00000000,1,1,4,0,0,0,0,{19},1} fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (00257CD8,1,L"AddRef",1), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (00257CD8,2,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610612738,00000000,00000000,1,1,4,0,0,0,0,{19},1} fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (00257CD8,2,L"Release",1), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (00259F08,0,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678272,00000000,0022FD80,1,1,4,1,0,0,0,{25},1} fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (00259F08,0,L"GetTypeInfoCount",2), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (00259F08,1,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678273,00000000,0022FD80,1,1,4,3,0,0,0,{25},1} fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (00259F08,1,L"GetTypeInfo",4), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (00259F08,2,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678274,00000000,0022FD80,1,1,4,5,0,0,0,{25},1} fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (00259F08,2,L"GetIDsOfNames",6), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (00259F08,3,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678275,00000000,0022FD80,1,1,4,8,0,0,0,{25},1} fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc Unrecognized type 12. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (00259F08,3,L"Invoke",9), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (0025C138,0,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678272,00000000,0022FD80,1,1,4,3,0,0,0,{25},0} fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc Unrecognized type 12. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (0025C138,0,L"Next",4), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (0025C138,1,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678273,00000000,0022FD80,1,1,4,1,0,0,0,{25},0} fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (0025C138,1,L"Skip",2), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (0025C138,2,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678274,00000000,00000000,1,1,4,0,0,0,0,{25},0} fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (0025C138,2,L"Reset",1), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc (0025C138,3,0022FE90), stub! fixme:typelib2:ICreateTypeInfo2_fnAddFuncDesc {1610678275,00000000,0022FD80,1,1,4,1,0,0,0,{25},0} fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ctl2_encode_typedesc PTR vartype, may not work correctly. fixme:typelib2:ICreateTypeInfo2_fnSetFuncAndParamNames (0025C138,3,L"Clone",2), stub!

Aug. 29, 2004

Re: CommonUnimpStub looping

by Steven Edwards

Hi, --- Mike Hearn <mike(a)navi.cx> wrote: > Unfortunately the only way to fix this one so it works out of the box > is > to force advapi32 to always load builtin, and never native. I'm not > sure > what Alexandres policy on modifying the default DLL overrides in the > source is. Last time I submitted a patch to change the internal table > it > was rejected. I dont see how native loading of Advapi32 ever worked anyway. Its a case like ntdll, kernel32, user32 or gdi. Maybe the Win9x advapi32 can..... Thanks Steven _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

Aug. 29, 2004

Re: mixing SHELL32.DLL and SHFOLDER.DLL

by Steven Edwards

Hi, --- Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > should I wait even more, or should I try writing a patch on my own? Write your own. Everyone else seems to have other stuff they are working on. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail

Aug. 29, 2004

mixing SHELL32.DLL and SHFOLDER.DLL

by Saulius Krasuckas

Using native version of SHELL32.DLL (from the Win98 install) and builtin version of SHFOLDER.DLL ends up in Wine failure: [s2(a)katleriai wine]$ WINEDLLOVERRIDES="shell32=n" WINEDEBUG=+loaddll wine /home/s2/cc/Program\ Files/mIRC/mirc 2>&1 | grep -i [^a-z]sh trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\shell32.dll" : native trace:loaddll:MODULE_LoadModule16 Loaded module "shell.dll" : native trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shfolder.dll" : builtin err:module:find_forwarded_export function not found for forward 'shell32.SHGetFolderPathA' used by L"c:\\windows\\system\\shfolder.dll". If you are using builtin L"shfolder.dll", try using the native one instead. err:commdlg:DllMain Failed to get entry point "SHGetFolderPathA" for hinst = 0x41930000 This situation was already discussed three years ago or so [1], [3]. The most initiative person here was Juergen Schmied, it seems. Besides another things on Sun, 03 Dec 2000, Juergen Schmied wrote [2]: > Hmm, shlfolder is introduced for systems with a older version of > shell32.dll. I think we should use it just like it's done in cdlg32.c > and get the function with GetProcAdress. Bye the way: this way is used > in several cases of functions within shell32 introduced in later > versions. I'm currently having a patch for comdlg32 and shell32 to the > imports. Will send it soon. AFAICS, there was no patches sent against the SHFOLDER.DLL. Dear Wine developers, can I expect this situation to change soon? Please tell me: should I wait even more, or should I try writing a patch on my own? TIA. [1] http://www.winehq.org/hypermail/wine-devel/2000/12/index.html#41 [2] http://www.winehq.org/hypermail/wine-devel/2000/12/0048.html [3] http://www.winehq.org/hypermail/wine-devel/2001/07/index.html#4

Aug. 29, 2004

Re: Winrash / Winetest

by Ferenc Wagner

"Stephen Ogletree" <jhk37pt02(a)sneakemail.com> writes: > (I sent a version of this to wine-users originally and Ivan said to > send it over here to wine-devel) Yes, it's better sent here. Thanks for the report and sorry for the long delay. It's still summer... > 0. Small issue: The winrash installer (NSIS) concludes with a window > that has 3 lines that are in blue text to suggest a hyperlink [...] I think the winrash maintainer got the message. > Since installing winrash didn't do anything except put the service in > place and start it, I figured I'd go ahead and download the test > manually. Well, the service should download and run new tests as they got published. Unfortunately there is some error on server side so it doesn't work as expected. We will eventually fix it and you dormant service process will start working in the background. > This rest of this email pertains to > /winetest-200407091000-kevin-mingw.exe/ Running the winetest suite manually present the user some interaction which is hidden when invoked by the service. > 1. I received the "Can't parse subtests output of msvcrtd" message > during 'extraction'. I assume this is the same error Holly reported. In your case it probably means that msvcrtd.dll isn't installed on your system. > 2. I had a message indicating a timeout during the user32 tests > (before the network tests - this appears to be the same message Holly > reported). Also, I remember the timeout was occurring back when we > first tried out this testing program a month or two (or 3?) ago, so > its a bug thats been around a while. Yes, it's a bug in the user32 input tests, which I haven't tried to fix yet, but introduced the timeout instead. Wrong tests will also emerge in the future, it's better to handle them than hang with them... > 3. I am still seeing an error that I pointed out in the first round > (or a long time ago, at least..) of testing where the test crashes > Explorer That was a deliberate kill, not a crash. It's excluded now as far as I know. > FWIW: When I agreed to submit my test results, I did *not* receive any > warning about my log being too big. That warning was removed, we silently truncate now... :) -- Best wishes and thanks for you help, Feri.

Aug. 29, 2004

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES

by James Hawkins

I did a full cvs update on the wine tree, recompiled and installed, and the kazaa lite wizard does not crash when you click next. I'm not exactly sure what caused this, but it is great to be able to move on. Thanks for all the help. On Sun, 29 Aug 2004 09:38:34 -0400, James Hawkins <truiken(a)gmail.com> wrote: > Here is the output of the program and the backtrace. > > > > On Sun, 29 Aug 2004 10:55:02 +0100, Robert Shearman <rob(a)codeweavers.com> wrote: > > James Hawkins wrote: > > > > >>This is all just speculation, but maybe it's possible that Kazaa uses a > > >>non-standard control in it's code? > > >> > > >> > > If it works on Windows 2000, for example, (or using comctl32.dll v5.81 > > instead of v6) then this is not the cause. > > > > >On Sat, 28 Aug 2004 22:17:24 -0400, > > >michael(a)cherryblossom.homelinux.com > > ><michael(a)cherryblossom.homelinux.com> wrote: > > > > > > > > >>On Fri, Aug 27, 2004 at 12:53:36PM -0400, James Hawkins wrote: > > >> > > >> > > >>>I'm reading through msdn some more and they say ICC_STANDARD_CLASSES should > > >>> > > >>>"Load one of the intrinsic User32 control classes. The user controls > > >>>include button, edit, static, listbox, combobox, and scrollbar." > > >>> > > >>>If I'm remembering, those controls are already implemented in > > >>>wine/controls. Maybe ICC_STANDARD_CLASSES just loads one/several of > > >>>these controls for the user. I'm really not sure though, and I'm sure > > >>> > > >>> > > >>This is all just speculation, but maybe it's possible that Kazaa uses a > > >>non-standard control in it's code? That wouldn't surprise me, > > >>especially when one considers the complex peer-to-peer concepts behind > > >>how it works. > > >> > > >> > > It doesn't use common controls to implement its peer-to-peer concepts. > > > > >>>On Fri, 27 Aug 2004 12:48:03 -0400, James Hawkins <truiken(a)gmail.com> wrote: > > >>> > > >>> > > >>>>the installation of klite, a program called KLConfigWizard.exe is run. > > >>>> It's a dialog box with some text initially, then when you click the > > >>>>next button, the user encounters a fatal error and we're sent to the > > >>>>debugger. > > >>>> > > Could you send me the backtrace and/or try the patch in this message: > > http://www.winehq.org/hypermail/wine-patches/2004/08/0520.html > > > > >>>> The error is: > > >>>> > > >>>>fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 > > >>>> > > >>>> The unknown class is one of the two control classes left to be > > >>>>implemented in commctrl: ICC_STANDARD_CLASSES. > > >>>> > > Assuming that the program works on operating systems older than XP, this > > message is not the cause of your problems. > > > > >>>> I would like to > > >>>>implement this class, but I have no idea where to start. I've > > >>>>searched msdn for ICC_STANDARD_CLASSES, but it only turned up a link > > >>>>to the INITCOMMONCONTROLSEX structure. If anyone has any ideas or > > >>>>hints that they can give me, I would really appreciate it. Thanks for > > >>>>your time. > > >>>> > > >>>> > > To implement ICC_STANDARD_CLASSES would mean copying a bunch of code > > from user32 (or being really clever and somehow reusing it) and then > > implementing the few new messages, which usually involve being able to > > use image lists and using themes. > > > > Rob > > > > > > > -- > James Hawkins > > > -- James Hawkins

Aug. 29, 2004

Re: winetest can't parse subtest for msvcrt(d)

by Ferenc Wagner

Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > On 27 Aug 2004, Vincent Béron wrote: > >> Just redirecting it to glibc would be trivial, but the problem is that's >> not the Right Thing To Do (tm) as both don't have exactly the same >> behavior, and that some apps rely on the msvcrt behavior (ie, break when >> using glibc's). > > This part if fine. Now please tell me: why printing result of msvcrt* > tests should depend on the difference of this behaviour? I mean, why do > we need msvcrt functions to print information about the behaviour of > another msvcrt functions? I always used to thought this is extremely > uncorrelated stuff: > > 1, testing function of the lib; > 2, printing results of the test. > > Are both thingies hardly tied? Forgive my ignorance, but I am afraid I > won't be able to undrestand this just by digging in the Wine src. Thanks. You are absolutely right, these two things should have nothing to do to each other. On my part it's simply that I've got no idea how to make that distinction. Wine's testing framework (test.h) uses fprintf() to do its output. It usually means glibc's fprintf(), but in the msvcrt* tests in means that of msvcrt, since those tests are linked with -lmsvcrt explicitly before the implicit -lc for the very purpose of the tests. So it's pure technicality at this end (at the other it's the matter of fixing msvcrt to take glibc redirection into account), which I didn't care enough to find a way to fix. It would be trivial if all the test used LoadLibrary() and GetProcAddress() to access the functions they test instead of linking them in, but it's not the case, especially not with such common and widely available functions as fprintf() for example. Hope I got the explanation right and that it makes sense for you. We are humans, that's to say... And finally a couple of winetest todos: 1. Implement the Stop button, like eg. first wait for the current test, then force termination. 2. Add an option the extract the tests and stop. 3. Ask for a Tag in the GUI (defaulting to the one given on the command line). 4. Add HTTP proxy support. 5. Remove mystrtok(), which isn't needed anymore. Out of these 3. and 4. would be the most useful additions, but the show seems to be stopped on the server side, so I will work there first. -- Feri.

Aug. 29, 2004