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

Looking for a Wine consultant

by Raetus Egli

I am sending this message for a friend of mine. I am the head of a company that is trying to migrate a VB6 system on WinNT to Linux. We would like to use this application under Debian Sarge using Wine. If you have experience in porting VB6 applications using Wine and have some free time to consult with an in-house developer it would be greatly appreciated. We would like to get the project up and running as soon as possible. If you are interested please get back to me at pyadegar(a)honeymae.com as soon as possible. Thanks.

Dec. 23, 2004

Re: Add ntoskrnl.exe.so

by Steven Edwards

--- Mike Hearn <mh(a)codeweavers.com> wrote: > Maybe. I'm not really convinced, they do totally different things. In > ReactOS it has to be a kernel, in Wine it just has to be a usermode DLL > that exports enough to please SafeDisc. I'd be amazed if much code sharing > is possible (or even necessary, how much code does SafeDisc need?) SafeDisk itself really needs very little but in the future we might support more than just this one driver. I admit the amount of code we might be able to share is limited I am just suggesting that we look at it now. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

Dec. 23, 2004

MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)

by Mike Hearn

Hi ho, Every so often I try out my favourite game to see how well it runs in Wine. This time, I found the demo (I have the full game but the demo is easier to debug) was working well! The following snowboarding game: http://www.housemarque.com/games/supremesb/ssb_demo.exe is not only a lot of fun but also Very Nearly There in Wine. There are only two problems preventing it from running perfectly: 1) There seems to be a bug in our msvcrt file reading APIs. I've chased this one before and got nowhere, but maybe somebody more familiar with the code can find it. We seem to pass back corrupt data: with builtin msvcrt the demo complains with a nicely detailed assertion that it can't find a file marker it's looking for. Native MSVCRT from WinXP makes it work (once you set winver=winxp) 2) When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's showing the pre-recorded demos the sky is just fine. The rest of the graphics are perfect. Finally if you put it in desktop mode, an X protocol error occurs initialising OpenGL. The XGetWindowAttributes call complains of a bad window. I debugged this for a bit and got nowhere, it wasn't as straightforward as it looked. Suffice to say that at the point it died opengl32.dll had been initialised several times already with the same value for root_window, and it worked each time previously (yes sync was enabled). I think this definitely used to work, so it feels like some WM rewrite regression to me. I could well be wrong though. This seems to affect all OpenGL+desktop mode apps. To make the game let you choose OpenGL in the setup program it has to be run in win2k/winxp mode. I do not know why. If you get it going, see if you can beat my best time (when playing on Linux) of 2:02. Have fun! :) thanks -mike

Dec. 23, 2004

Re: AppDB TODO update: Templates

by Stefan Pflüger

> Search engines don't like dynamic pages. So using the lostwages way > would really be preferred. > And we're trying to get rid of the tables and use CSS positioning. So > don't count on those. Al tough it won't change the main idea I think. > > Paul > > Well one could easily ship around the search engine problem by a) Using mod_rewrite or b) Setting a var and including index.php from those files I'd prefer getting any HTML code out of appdb into the templates to make it easy to fully change the design without touching any line of PHP code. Changes in the design won't change anything in the concept. Stefan

Dec. 23, 2004

Re: Add ntoskrnl.exe.so

by Ivan Leo Puoti

> Maybe. I'm not really convinced, they do totally different things. In > ReactOS it has to be a kernel, in Wine it just has to be a usermode DLL > that exports enough to please SafeDisc. I'd be amazed if much code sharing > is possible (or even necessary, how much code does SafeDisc need?) I've just sent two patches, AJ can choose, even if I tend to agree that ntoskrnl in wine should be a usermode dll. Ivan.

Dec. 22, 2004

Looking for a Wine consultant.

by Pouya Yadegar

I am the head of a company that is trying to migrate a VB6 system on WinNT and would like to use that application under Debian Sarge using Wine. If you have experience in porting VB6 applications using Wine and have some free time to consult an in house developer it would be appreciated. We would like to get the project up and running as soon as possible. If your interested please get back to me at pyadegar(a)honeymae.com as soon as possible. Thanks.

Dec. 22, 2004

Re: Add ntoskrnl.exe.so

by Mike Hearn

On Wed, 22 Dec 2004 14:12:22 -0800, Steven Edwards wrote: > Because if we design things properly from the start we can share more > code Wine <-> ReactOS. I am planning on making it a discussion topic > at WineConf. Maybe. I'm not really convinced, they do totally different things. In ReactOS it has to be a kernel, in Wine it just has to be a usermode DLL that exports enough to please SafeDisc. I'd be amazed if much code sharing is possible (or even necessary, how much code does SafeDisc need?)

Dec. 22, 2004

Re: My "Helping Applications Work" Guide

by Dan Kegel

Mike Hearn wrote: > This quote: "An alternative option, perhaps more effective and expensive, is to pay wine > developers for their work on your application, either directly through a > negotiated contract or indirectly by posting a bounty" ... could it have a > link to CodeWeavers please? I think it's fair to say that we're the number > one provider of these sorts of services by a long way, but currently we're > still quite dependent on people being able to find us, so additional links > and publicity is needed. Yeah, a link to http://codeweavers.com would be appropriate. You might want to link to a list of vendors who are willing to help update Wine to work with particular apps and contribute the fixes back to the winehq tree per the LGPL, e.g. http://codeweavers.com http://www.macadamian.com http://www.itomig.de Itomig's a newcomer, but what the heck, they seem to be interested in helping the Wine community. (Also maybe Transgaming, but I don't know if they're willing to work on the winehq tree anyore). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Dec. 22, 2004

Re: Add ntoskrnl.exe.so

by Ivan Leo Puoti

> Because if we design things properly from the start we can share more > code Wine <-> ReactOS. I am planning on making it a discussion topic > at WineConf. Well, the reactos code just has hardcoded values for PsGetVersion. I'll send another patch that adds PsGetVersion as a stub in case AJ agrees with you. Ivan.

Dec. 22, 2004

Re: Add ntoskrnl.exe.so

by Steven Edwards

--- Mike Hearn <mh(a)codeweavers.com> wrote: > Why not? This isn't ReactOS, ntoskrnl is just another DLL from the > SafeDisc perspective. Its implementation details shouldn't matter. Because if we design things properly from the start we can share more code Wine <-> ReactOS. I am planning on making it a discussion topic at WineConf. Thanks Steven __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

Dec. 22, 2004

Re: Add ntoskrnl.exe.so

by Mike Hearn

On Wed, 22 Dec 2004 13:29:35 -0800, Steven Edwards wrote: > kernel32 can't be a dependancy on ntoskrnl. We are going to need to redesign Wine if we are going > to have a ntoskrnl implementation. Why not? This isn't ReactOS, ntoskrnl is just another DLL from the SafeDisc perspective. Its implementation details shouldn't matter.

Dec. 22, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by Mike Hearn

On Wed, 2004-12-22 at 14:18 -0700, tony_lambregts(a)telusplanet.net wrote: > Anyways I was wondering I anyone could give me an update Huw is working on adding TLB output support to widl, so hopefully we should have a stdole32.tlb out of the box within a month or so (maybe earlier). The rest of the work involves simply improving our DCOM code to make InstallShield work correctly. Here are the issues I know about already: - stdole32.tlb needed, see above - painting problems (ie it doesn't draw right): needs thread affinity, which in turn needs correct RPC re-entrancy - iTunes installer hangs at the end, refcount leak triggered I think by InstallShield throwing across non-exception safe code when it hits an MSI stub - InstallShield 8 (9?) doesn't start up ... thanks -mike

Dec. 22, 2004

Re: Add ntoskrnl.exe.so

by Steven Edwards

Hi, --- Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > Add ntoskrnl, only a few stub functions for now, so we have something to > work on. > All the functions needed by safedisc are in the spec, we can't implement > them all > as stubs ATM because for two of them we need defines from the ddk, > I'll be sending a patch to add ntddk.h in the near future. Check the ReactOS or w32api DDK. Its public domain. > +MODULE = ntoskrnl.exe > +IMPORTS = kernel32 > +DLLMODE = native kernel32 can't be a dependancy on ntoskrnl. We are going to need to redesign Wine if we are going to have a ntoskrnl implementation. > +BOOLEAN WINAPI PsGetVersion(PULONG MajorVersion OPTIONAL, PULONG MinorVersion OPTIONAL, > + PULONG BuildNumber OPTIONAL, PUNICODE_STRING CSDVersion > + OSVERSIONINFOA version; > + version.dwOSVersionInfoSize=sizeof(OSVERSIONINFOA); > + GetVersionExA(&version); We need to either duplicate or move the version code in to ntoskrnl.exe. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

Dec. 22, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by tony_lambregts＠telusplanet.net

Robert Shearman wrote: > tony_lambregts(a)telusplanet.net wrote: > >> I just want to say that I tried out this patch. It does not fix the >> problem for InstallShield 6. I have a bug report in bugzilla if you >> are interested. Right now AFAIKT InstallSheild is seriously broken >> (for quite some time) and I am unable to use Native ole to workaround >> the problem. > > > > Why does native ole not work? Because I did not have stdole32.tlb since I usually run wine with no windows files. ;^) When I applied Mikes patch and imported a stdole32.tlb file from windows the program installs. Not having our own version of stdole32.tlb means that the at least InstallShield 6 will not work "out of the box". We have had a couple of proposals for implementing our own version of stdole32.tlb. Huw Davies' is the most recent, it was submitted to wine patches by Vincent Béron. http://www.winehq.org/hypermail/wine-patches/2004/12/0053.html. and the most recent discussion thread is here. http://www.winehq.org/hypermail/wine-devel/2004/12/0164.html . The upshot of which was that Alexandre said that it should be installed at compile time. Anyways I was wondering I anyone could give me an update. > >> If there is anyway I can help this process I please tell me. > > > > If you don't want to assist us in the programming work, then you can > help us by testing things that should work (I'll include a comment in my > message to wine-patches if I think something should start working with > the patch). Each program's InstallShield seems to be unique and they > usually break in unique ways, so any help with testing different > installers would be greatly appreciated. > > Rob > > I am currently building wine with Vincent's and Mike's patches applied to see if it will install without native stdole32.tlb. I will let you know what the results are. -- Tony Lambregts

Dec. 22, 2004

Re: AppDB TODO update: Templates

by Stefan Pflüger

Chris Morgan wrote: >I think you are covering the appropriate mailing lists. If you'd like to chat in real-time about hacking appdb, channel #winehackers on irc.freenode.net is a good place. Tony, Jon and myself are frequently there and chat at least every other day about appdb related things. > >About the templates, is this what Jeremy did in the lostwages archive(www.winehq.org/cvsweb/lostwages)? I wasn't too familiar with the changes he made and thought it would be good to discuss things prior to making such large changes to the appdb code. Anything that improves the design is more than welcome. > >Chris > > > Fundamentally, it's the same concept. I'll first just implement the template system without changing lots of code and then change the files (pages) one by one, as suggested by jernst. Stefan

Dec. 22, 2004

Re: AppDB TODO update: Templates

by Stefan Pflüger

Basically, I'll implement a class that is able to read a template file and that can assign content to special tags in there. The index.php would create an object of this class using a "main template" that includes all parts of the page that are static (header, footer, the main html tables). Depending on a GET variable, the index.php calls a function whose returned data will be used as the main content, it would be for example index.php?action=browseapps to get to the "Browse Apps" page. The content of the sidebar, the banner ad etc. would also be created by a function like it's already done (see banner_display() in include/banner.php), but instead of just echo-ing this somewhere in the right place, it would also be fed into the template engine that again replaces the corresponding tags in the main template. Those functions might also use the template class to implement their own sub-templates. In the end, the template class object in index.php should have the complete output ready for sending it to the user. Hopefully, my short explanation was good enough to illustrate the concept. Stefan PS.: What's the correct list/address to send mails concerning this discussion to? I'm sending them to the wine-devel list atm, CCing to Chris Morgan and appdb(a)winehq.org...

Dec. 22, 2004

Re: Re: AppDB TODO update: Templates

by Chris Morgan

I think you are covering the appropriate mailing lists. If you'd like to chat in real-time about hacking appdb, channel #winehackers on irc.freenode.net is a good place. Tony, Jon and myself are frequently there and chat at least every other day about appdb related things. About the templates, is this what Jeremy did in the lostwages archive(www.winehq.org/cvsweb/lostwages)? I wasn't too familiar with the changes he made and thought it would be good to discuss things prior to making such large changes to the appdb code. Anything that improves the design is more than welcome. Chris > > From: Stefan Pflüger <stefan(a)homepage4us.de> > Date: 2004/12/22 Wed PM 02:33:18 EST > To: wine-devel(a)winehq.org > CC: cmorgan(a)alum.WPI.EDU, appdb(a)winehq.org > Subject: Re: AppDB TODO update: Templates > > Basically, I'll implement a class that is able to read a template file > and that can assign content to special tags in there. > > The index.php would create an object of this class using a "main > template" that includes all parts of the page that are static (header, > footer, the main html tables). Depending on a GET variable, the > index.php calls a function whose returned data will be used as the main > content, it would be for example index.php?action=browseapps to get to > the "Browse Apps" page. > > The content of the sidebar, the banner ad etc. would also be created by > a function like it's already done (see banner_display() in > include/banner.php), but instead of just echo-ing this somewhere in the > right place, it would also be fed into the template engine that again > replaces the corresponding tags in the main template. Those functions > might also use the template class to implement their own sub-templates. > > In the end, the template class object in index.php should have the > complete output ready for sending it to the user. > > Hopefully, my short explanation was good enough to illustrate the concept. > > > Stefan > > PS.: What's the correct list/address to send mails concerning this > discussion to? I'm sending them to the wine-devel list atm, CCing to > Chris Morgan and appdb(a)winehq.org... > >

Dec. 22, 2004

Re: Writing an app. using existing dll

by Jakob Eriksson

Per Arnold Blåsmo skrev: > Hi, > > I have a windows-dll and wants to make an app that runs on Linux under > wine using this dll. I have the API description for this dll, but not > the source code. > > I there any possibility for that using i.e. winelib and is there any > howto to get me started. > > PerA. > It is easiest to compile a Windows program using the mingw tools. Easiest to download are Bloodshed Dev-cpp on Windows and mingw-gcc on Debian. Put you DLL in the same directory as the Windows EXE you compiled and run Wine on it. Once that succeds, you can start doing a Winelib port. regards, Jakob

Dec. 22, 2004

AppDB TODO update: Templates

by Stefan Pflüger

Hello, the last update added +# incorporate templates into appdb to simplify code, Jeremy says we can +borrow from lostwages(winehq.org/cvsweb/lostwages) for this to the TODO file. At the moment, I'm trying to use AppDB for another project and I already planned on implementing templates. If nobody else wants to do the job, I'll go ahead and send you a patch as soon as I'm finished. Stefan Pflüger

Dec. 22, 2004

Re: AppDB TODO update: Templates

by tony_lambregts＠telusplanet.net

Stefan Pflüger wrote: > Hello, > > the last update added > > +# incorporate templates into appdb to simplify code, Jeremy says we can > +borrow from lostwages(winehq.org/cvsweb/lostwages) for this > > to the TODO file. > > At the moment, I'm trying to use AppDB for another project and I already > planned on implementing templates. > If nobody else wants to do the job, I'll go ahead and send you a patch > as soon as I'm finished. > > Stefan Pflüger > That would be wonderfull. Perhaps you should submit a patch indicateing that you are working on it. -- Tony Lambregts.

Dec. 22, 2004

Re: AppDB TODO update: Templates

by Chris Morgan

Cool, thanks for claiming this so we don't have people stepping on each others toes. Would you mind showing a little bit of what you planned on changing? It would be nice to have agreement that this was the direction we wanted to go before a big patch was submitted. Chris > > From: Stefan Pflüger <stefan(a)homepage4us.de> > Date: 2004/12/22 Wed PM 01:05:06 EST > To: wine-devel(a)winehq.org > CC: appdb(a)winehq.org > Subject: AppDB TODO update: Templates > > Hello, > > the last update added > > +# incorporate templates into appdb to simplify code, Jeremy says we can > +borrow from lostwages(winehq.org/cvsweb/lostwages) for this > > to the TODO file. > > At the moment, I'm trying to use AppDB for another project and I already > planned on implementing templates. > If nobody else wants to do the job, I'll go ahead and send you a patch > as soon as I'm finished. > > Stefan Pflüger > >

Dec. 22, 2004

Re: Implement DceErrorInqText

by Bill Medland

On December 22, 2004 08:25 am, Alexandre Julliard wrote: > Bill Medland <billmedland(a)mercuryspeed.com> writes: > > Oh. I thought we wanted to do the same as Windows does!!! > > > > Don't ask me why but for some error codes (as detailed in the patch), > > even though FormatMessage can return a perfectly reasonable string, > > DceErrorInqText doesn't return it. E.g. 7050, 7052 and 7053 but not > > 7051. > > I really doubt that Windows has a list of magic codes where it > deliberately ignores the correct error from FormatMessage to return > the generic error instead. So either our FormatMessage is wrong, or > there's something else going on here that we don't understand. Yes, you are right. It suddenly came to me. (It's the length of the string). I'll resubmit (Take 3) in a couple of minutes. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 22, 2004

Re: wine/dlls/cabinet cabextract.c

by Andreas Mohr

Hi, On Wed, Dec 22, 2004 at 11:11:32AM -0600, Alexandre Julliard wrote: > ChangeSet ID: 14986 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/12/22 11:11:32 > > Modified files: > dlls/cabinet : cabextract.c > > Log message: > Revert previous patch, that's not a leak. Nice, but... ;-) [get ready to read my usual "not commented" complaint] Why isn't there a comment nearby? 8 weeks later Joe Janitor 2's source code analyzer tool will strike gold again, and then you'll have fun with another patch "correcting" things that turn(ed) out shouldn't be corrected... Andreas Mohr

Dec. 22, 2004

Re: Implement DceErrorInqText

by Alexandre Julliard

Bill Medland <billmedland(a)mercuryspeed.com> writes: > Oh. I thought we wanted to do the same as Windows does!!! > > Don't ask me why but for some error codes (as detailed in the patch), even > though FormatMessage can return a perfectly reasonable string, > DceErrorInqText doesn't return it. E.g. 7050, 7052 and 7053 but not 7051. I really doubt that Windows has a list of magic codes where it deliberately ignores the correct error from FormatMessage to return the generic error instead. So either our FormatMessage is wrong, or there's something else going on here that we don't understand. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2004

Re: Implement DceErrorInqText

by Bill Medland

On December 22, 2004 06:47 am, Alexandre Julliard wrote: > Bill Medland <billmedland(a)mercuryspeed.com> writes: > > My comments are probably not clear enough. That function isn't asking if > > the error code is a valid error code (which is relevant to > > FormatMessage). Actually !acceptable_rpc_code is the list of error codes > > for which FormatMessage will return a valid string but that is not the > > string that DceErrorInqText returns; it returns the "not a valid rpc > > code" message. I'll reword the comments and rename the function. > > I can't imagine a case where an app would depend on getting a generic > error message instead of a detailed one; it seems to me that if > FormatMessage returns something meaningful we should use it. Oh. I thought we wanted to do the same as Windows does!!! Don't ask me why but for some error codes (as detailed in the patch), even though FormatMessage can return a perfectly reasonable string, DceErrorInqText doesn't return it. E.g. 7050, 7052 and 7053 but not 7051. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 22, 2004

Re: Getting rid of async.h

by Alexandre Julliard

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > - we maintain on the client side whether there's still some pending > async op on the current thread (this is needed in optimizing some wait > operations) That part doesn't look right, you clear the flag when removing the last async operation on an fd, but this bears no relation to the number of async operations in the current thread. It seems to me this could instead be done entirely on the client side, since we need to allocate and free an async structure for each operation we should be able to maintain a counter of them on the client side. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2004

Re: ntdll / kernel32: #52

by Alexandre Julliard

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > +/* FIXME: 0xFFFFFFFF is our shortcut for global table > + * we could also tweak init_atom_table request to get a handle to the > + * global table in wineserver > + */ > +#define GLOBAL_ATOM_TABLE ((void*)0xFFFFFFFF) Yes, you need to get a valid handle here, 0xffffffff is the current process pseudo-handle and we don't want to overload that meaning. Also your local table allocation is not thread-safe, it can potentially leak an atom table. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2004

Re: Implement DceErrorInqText

by Alexandre Julliard

Bill Medland <billmedland(a)mercuryspeed.com> writes: > My comments are probably not clear enough. That function isn't asking if the > error code is a valid error code (which is relevant to FormatMessage). > Actually !acceptable_rpc_code is the list of error codes for which > FormatMessage will return a valid string but that is not the string that > DceErrorInqText returns; it returns the "not a valid rpc code" message. > I'll reword the comments and rename the function. I can't imagine a case where an app would depend on getting a generic error message instead of a detailed one; it seems to me that if FormatMessage returns something meaningful we should use it. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2004

Re: Implement DceErrorInqText

by Bill Medland

On December 21, 2004 10:50 pm, Dmitry Timoshkov wrote: Thanks for the feedback > "Bill Medland" <billmedland(a)mercuryspeed.com> wrote: > > +RPC_STATUS RPC_ENTRY DceErrorInqTextW (unsigned long e, unsigned short > > *b) +{ > > + DWORD count; > > + if (acceptable_rpc_code (e)) > > It would be much more natural to make FormatMessageW to decide whether a > passed error code is valid or not, i.e. if it exists in the system message > table. My comments are probably not clear enough. That function isn't asking if the error code is a valid error code (which is relevant to FormatMessage). Actually !acceptable_rpc_code is the list of error codes for which FormatMessage will return a valid string but that is not the string that DceErrorInqText returns; it returns the "not a valid rpc code" message. I'll reword the comments and rename the function. The model has been tested for error codes 0 to 0x10000000 against rpcrt4 5.0.2195.6904. I considered two models: a. If (valid_rpc_code) if (FormatMessage) return the message else return error else return the invalid message b. if (FormatMessage) if (valid rpc code) return the message else return the invalid one else return the invalid one. The second model requires a much smaller list of deviations; messages for which FormatMessage returns a value but that value is not returned by DceErrorInqText. > > > + { > > + count = FormatMessageW (FORMAT_MESSAGE_FROM_SYSTEM | > > + FORMAT_MESSAGE_IGNORE_INSERTS, > > + NULL, e, 0, b, /* I don't know!!! */ 65535, NULL); > > 256 (or 1024) is a reasonable margin I believe, at least messages in Wine > are much shorter of even 256. And there was me considering ULONG_MAX!!!. Basically I am not putting in a limit; it isn't my place to say. If the documentation gave a limit I'd use it, but since it doesn't I assume that the caller provided a sufficient buffer. > > > + } > > + else > > + count = 0; > > + if (!count) > > + { > > + MultiByteToWideChar(CP_ACP, 0, cszInvalidCode, -1, b, 65535 /* > > ??? */); > > A message about invalid code should be localizable as well, so it should be > either loaded by LoadString or even by FormatMessage for consistency IMO. > winerror.h from PlatformSDK has the following definition which matches your > error text ("The error specified is not a valid Windows RPC error > code.\r\n"): > > // > // MessageId: RPC_S_NOT_RPC_ERROR > // > // MessageText: > // > // The error specified is not a valid Windows RPC error code. > // > #define RPC_S_NOT_RPC_ERROR 1823L Aha; there it is. Thanks. I'll fix it up. (And that shortens the list of deviations by 1 too) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 22, 2004

Re: test.h: problem with ok's argument evaluation order

by Alexandre Julliard

Rein Klazes <wijn(a)wanadoo.nl> writes: > --- wine/include/wine/test.h 2004-05-04 08:10:39.000000000 +0200 > +++ mywine/include/wine/test.h 2004-12-20 15:29:39.000000000 +0100 > @@ -53,7 +53,8 @@ extern void winetest_trace( const char * > > #endif /* __GNUC__ */ > > -#define ok_(file, line) (winetest_set_location(file, line), 0) ? 0 : winetest_ok > +#define winetest_ok_(cond, args...) (cond) ? winetest_ok(TRUE, args) : winetest_ok(FALSE, args) > +#define ok_(file, line) (winetest_set_location(file, line), 0) ? 0 : winetest_ok_ Unfortunately varargs macros are not portable. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2004

Re: Approving of the WINEprobe initiative

by Scott Ritchie

On Wed, 2004-12-22 at 11:39 +0100, David Gümbel wrote: > Hi everybody, > > Yep, I think you all made a point when saying "probe" in english is really > not quite... optimal ;) I personally like the PortWine idea very much - > we'll consider renaming the initiative accordingly. > I request 20% of all name-change related fan-mail ;) Danke, Scott Ritchie

Dec. 22, 2004

Re: Approving of the WINEprobe initiative

by David Gümbel

Hi everybody, Mike Hearn schrieb am 21.12.2004 um 17:33 Uhr: > On Mon, 20 Dec 2004 19:13:00 +0100, David Gümbel wrote: > > its actually a pun: WINEprobe means be something like WINEtasting in > > english an maybe "degustation de WINE" in french. It's a little hard to > > translate puns, sorry ;) Maybe this is helpful: > > http://dict.leo.org/?search=weinprobe > > Still, I personally would rather have a name that made sense in English - > WineProbe isn't exactly intuitive. PortWine is a good name. Yep, I think you all made a point when saying "probe" in english is really not quite... optimal ;) I personally like the PortWine idea very much - we'll consider renaming the initiative accordingly. By now, I wanted to thank all of you who have provided feedback and ideas. I will wait a little more time in case somebody who hasn't spoken up yet wishes to do so :) Bye, David

Dec. 22, 2004

Writing an app. using existing dll

by Per Arnold Blåsmo

Hi, I have a windows-dll and wants to make an app that runs on Linux under wine using this dll. I have the API description for this dll, but not the source code. I there any possibility for that using i.e. winelib and is there any howto to get me started. PerA.

Dec. 22, 2004

Re: Implement DceErrorInqText

by Dmitry Timoshkov

"Bill Medland" <billmedland(a)mercuryspeed.com> wrote: > +RPC_STATUS RPC_ENTRY DceErrorInqTextW (unsigned long e, unsigned short *b) > +{ > + DWORD count; > + if (acceptable_rpc_code (e)) It would be much more natural to make FormatMessageW to decide whether a passed error code is valid or not, i.e. if it exists in the system message table. > + { > + count = FormatMessageW (FORMAT_MESSAGE_FROM_SYSTEM | > + FORMAT_MESSAGE_IGNORE_INSERTS, > + NULL, e, 0, b, /* I don't know!!! */ 65535, NULL); 256 (or 1024) is a reasonable margin I believe, at least messages in Wine are much shorter of even 256. > + } > + else > + count = 0; > + if (!count) > + { > + MultiByteToWideChar(CP_ACP, 0, cszInvalidCode, -1, b, 65535 /* ??? */); A message about invalid code should be localizable as well, so it should be either loaded by LoadString or even by FormatMessage for consistency IMO. winerror.h from PlatformSDK has the following definition which matches your error text ("The error specified is not a valid Windows RPC error code.\r\n"): // // MessageId: RPC_S_NOT_RPC_ERROR // // MessageText: // // The error specified is not a valid Windows RPC error code. // #define RPC_S_NOT_RPC_ERROR 1823L -- Dmitry.

Dec. 22, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by Mike Hearn

On Tue, 2004-12-21 at 12:46 -0800, Bill Medland wrote: > I'm certainly interested but I think that I am not going to have the time. > (Presumably it will take quite a while to get up to speed). I don't know. Some tasks are not that hard, for instance making apartments into thread-safe COM objects. Others are more tricky. I'm happy to answer any questions you have, if you decide to go ahead. thanks -mike

Dec. 22, 2004

Merging the AppDB Documentation and the WineHQ documentation pages

by Scott Ritchie

Mike said this about my new "helping applications work" page: >Looks great! I'd suggest putting it in the Documentation section, and >then linking to it from the appdb page. This then prompted me to wonder "which documentation section?" This is kind of confusing: I click on documentation at the main wine page, and I get some useful stuff. I wander into the AppDB page, click on documentation, and I get some different stuff. Methinks we should just dump them all into one page. This has the added benefit of informing people without the wherewithal to click "Applications" that there is, in fact, an AppDB. On another note, it looks like the AppDB documentation is in PHP, rather than the normal template format like the rest of the website. Is this a good idea? Thanks, Scott Ritchie

Dec. 21, 2004

Re: Hyperthreading and SMP

by Kenneth Porter

--On Tuesday, December 21, 2004 4:57 PM -0500 Kuba Ober <kuba(a)mareimbrium.org> wrote: > What kernel version were you running under? Could that be related at all > to thread CPU affinity under 2.6? 2.6.8-1.521smp on Fedora Core 2. What's the issue you're referring to?

Dec. 21, 2004

Re: Hyperthreading and SMP

by Kuba Ober

On wtorek 21 grudzień 2004 12:46 pm, Kenneth Porter wrote: > Does WINE have any problem with either Hyperthreading or SMP? I've found > that locking the Tribes Vengeance dedicated server to a single logical CPU > seems to give me better performance as the server fills with players. CPU > usage seems significantly lower (45% versus 65%). Is this likely to be a > WINE issue or a TV issue? (TV is based on the Unreal Tournament engine, > with the Havok physics engine integrated to handle vehicle. Alas, unlike > UT2004, there's no native Linux server for TV.) What kernel version were you running under? Could that be related at all to thread CPU affinity under 2.6? Cheers, Kuba Ober

Dec. 21, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by Bill Medland

On December 21, 2004 11:59 am, Mike Hearn wrote: > On Tue, 2004-12-21 at 11:41 -0800, Bill Medland wrote: SNIP > > - Help us improve builtin DCOM (yay!) > - Hack the registry and manually expand the strings so MSXML is happy > > If you're able to commit time to the first one then perhaps Rob and I > should draw up a more detailed roadmap. Quite a few of the tasks can be > done in parallel. I'm certainly interested but I think that I am not going to have the time. (Presumably it will take quite a while to get up to speed). > > Of course, first we have to resolve the matter of the patch I sent > earlier ... -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 21, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by Mike Hearn

On Tue, 2004-12-21 at 11:41 -0800, Bill Medland wrote: > I suggest as a working hypothesis that the Win95/98 > ole32 does not support the REG_EXPAND_SZ. (Does the Windows 98 Registry code > actually allow you to add a REG_EXPAND_SZ to the registry or doe it maybe > automatically do the expansion on the way into the registry?) I think DCOM98 is just buggy. That sort of thing works on Windows XP. Unfortunately XP DCOM doesn't work on Wine, so you have a few options: - Help us improve builtin DCOM (yay!) - Hack the registry and manually expand the strings so MSXML is happy If you're able to commit time to the first one then perhaps Rob and I should draw up a more detailed roadmap. Quite a few of the tasks can be done in parallel. Of course, first we have to resolve the matter of the patch I sent earlier ...

Dec. 21, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by Bill Medland

On December 21, 2004 04:25 am, Mike Hearn wrote: SNIP > > Native OLE should still work - is this the REG_EXPAND_SZ issue Bill > mentioned? What exactly is this issue? (It was mentioned early on in that IRC hecking discussion a couple of Sundays ago, although I met it a few days earlier) Due to some change after the September version, native msxml registers itself using REG_EXPAND_SZ entries in the registry, which is what it seems to do on a Windows 2000 computer. However the native ole32 that I use (which comes from I can't remember where) does not expand the string and so the msxml stuff stops working. I suggest as a working hypothesis that the Win95/98 ole32 does not support the REG_EXPAND_SZ. (Does the Windows 98 Registry code actually allow you to add a REG_EXPAND_SZ to the registry or doe it maybe automatically do the expansion on the way into the registry?) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 21, 2004

Hyperthreading and SMP

by Kenneth Porter

Does WINE have any problem with either Hyperthreading or SMP? I've found that locking the Tribes Vengeance dedicated server to a single logical CPU seems to give me better performance as the server fills with players. CPU usage seems significantly lower (45% versus 65%). Is this likely to be a WINE issue or a TV issue? (TV is based on the Unreal Tournament engine, with the Havok physics engine integrated to handle vehicle. Alas, unlike UT2004, there's no native Linux server for TV.) More here: <http://lists.matureasskickers.net/pipermail/tvservers/2004-December/000186.…> I want to try disabling HT or setting affinity on my co-admin's Win2003 server to see if he sees the same boost.

Dec. 21, 2004

Re: Approving of the WINEprobe initiative

by Mike Hearn

On Mon, 20 Dec 2004 19:13:00 +0100, David Gümbel wrote: > its actually a pun: WINEprobe means be something like WINEtasting in > english an maybe "degustation de WINE" in french. It's a little hard to > translate puns, sorry ;) Maybe this is helpful: > http://dict.leo.org/?search=weinprobe Still, I personally would rather have a name that made sense in English - WineProbe isn't exactly intuitive. PortWine is a good name.

Dec. 21, 2004

Re: wine/dlls/cabinet cabextract.c

by Mike McCormack

This patch breaks IE6 install. Mike Alexandre Julliard wrote: > ChangeSet ID: 14647 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/12/02 11:55:41 > > Modified files: > dlls/cabinet : cabextract.c > > Log message: > James Hawkins <truiken(a)gmail.com> > Fix cabextract memory leak. > > Patch: http://cvs.winehq.org/patch.py?id=14647 > > Old revision New revision Changes Path > 1.15 1.16 +2 -0 wine/dlls/cabinet/cabextract.c

Dec. 21, 2004

Some performance stats

by Dmitry Timoshkov

Hello all, while debugging one of applications I'm working on I noticed a lot of GetPrivateProfileString calls with the same file name but in different case causes profile code to open and parse system.ini again. I sent a patch which helps to find a cached file in that case and do not parse it again. I had a thought that another speed improvement might be to use FindFirstFileW instead of CreateFileW/GetFileTime to retrieve last modification time of a file. I wrote a test under Windows to see which of FindFirstFileW or CreateFileW is faster. The test is attached. Here are the results (for 10000 loops) running the same binaries in Wine and Windows 2000 SP4 (hard disks are the same in both systems): =================================================================== Win2k SP4/NTFS volume: test_CreateFileW: P3/1GHz time elapsed 363 ms test_FindFirstFileW: P3/1GHz time elapsed 547 ms Wine/ext3 volume: test_CreateFileW: P3/1GHz time elapsed 543 ms test_FindFirstFileW: P3/1GHz time elapsed 1650 ms =================================================================== CreateFileW is only 1.5 times slower in Wine than in Windows, that's really not bad (especially taking into account Wine boot time), but still there is a possibility for an improvement. FindFirstFileW is 3 times slower in Wine than CreateFileW, while it's only 1.5 times slower in Windows. This needs to be optimized. -- Dmitry.

Dec. 21, 2004

wine-alsa gives compile errors

by Joris Huizer

Hello, I'm not sure where to post this, so posting to wine-users and wine-devel; I got wine sources from cvs and tried compiling it -- something seems to be wrong in the alsa code - it gives compile errors about functions getting too many arguments (I attached an error log) Hopefully this is fixed soon regards, Joris

Dec. 21, 2004

Re: [OLE #3] Tests For COM Functions (Try 2)

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: > This differs from the previous send of this patch by not using some > functions that are not present on Win9x and without DCOM95 and by > disabling the out-of-process COM tests, which seems to need more work, > but is useful for me testing locally. Dmitry, you reported to me before > that Win95 w/o DCOM95 does not export CoResumeClassObjects, but MSDN > claims that it does. Is MSDN wrong? Just checked Win95 OSR2 again: ole32.dll does not export CoResumeClassObjects. That's a clean system, without MS Office, DCOM95 or something like that. -- Dmitry.

Dec. 21, 2004

Re: Approving of the WINEprobe initiative

by Jakob Eriksson

David Gümbel wrote: >Jep, its actually a pun: WINEprobe means be something like WINEtasting in > > Or "vin-prov" in Swedish. Yet, I didn't make the connection, but still thought of unwanted probing of my body. :-) regards, Jakob (The Port-Wine idea was good though.)

Dec. 21, 2004

Re: My "Helping Applications Work" Guide

by Mike Hearn

On Mon, 20 Dec 2004 18:38:20 -0800, Scott Ritchie wrote: > However, I'm not exactly sure where to put it on the winehq website. > Perhaps it should be linked from the main page of the applications > database, or from the support tab, or something. Anyway, I'm posting it > here for peer review. Looks great! I'd suggest putting it in the Documentation section, and then linking to it from the appdb page. This quote: "An alternative option, perhaps more effective and expensive, is to pay wine developers for their work on your application, either directly through a negotiated contract or indirectly by posting a bounty" ... could it have a link to CodeWeavers please? I think it's fair to say that we're the number one provider of these sorts of services by a long way, but currently we're still quite dependent on people being able to find us, so additional links and publicity is needed. Here: "An application may not work because Wine doesn't yet fully implement one of the DLL files the application is trying to use. If you encounter a DLL not found error, or see a lot of "FixMe:" messages while running the application in wine, this is likely the case." you may wish to mention that if you're a programmer, you should read the Getting Started guide and maybe the developer guide (in the documentation section). Rest looks fine to me. thanks -mike

Dec. 21, 2004

Re: [OLE #10] Make out of process COM work with OXID based marshal ids

by Mike Hearn

On Tue, 2004-12-21 at 10:55 +0000, Robert Shearman wrote: > And those same users would have been inconvenienced with the 20041201 > release. It wouldn't crash, but it's likely the program still wouldn't > work. Well, I think an engineering goal for us should be that WineHQ CVS is at all times: a) Internally consistent b) Working (even if it's not perfect) This is good for several reasons. Obviously it helps users, but it also helps us: more people can help out, whereas if the code is missing pieces only we know about anybody who is interested in coding alongside us will fall at the first hurdle (I was talking to somebody who seemed to know DCOM pretty well in IRC last night, no idea if he'll turn up and help but you never know). It helps in another way: it's easier to spot regressions if we have a baseline of "it works". That way when it stops working, we can figure out exactly which patch did it quickly. If the code simply crashes within a few yards of the first CoMarshalInterface call because we didn't put in the 6 lines of code necessary to keep it working during the transition, we have no idea if the code that comes later really works. If we're not going to try and keep CVS working then we shouldn't be submitting patches there, especially if native DCOM is busted. We should be working in a private arch or subversion/svk branch where it doesn't matter if we go a year with no InstallShield support. > I'll see what I can come up with this week. I know you have some work > on the stub manager outstanding and I think it would be fairly easy to > build on that work to implement the table marshaling. OK, you have the latest patch in your inbox. It's different from the previous but not much. If you think it's OK I'll go ahead and submit it (and I'll check it still works with InstallShield too). Once that patch is in you're right, table marshalling should be easy. At that point we can start to remove some of the extra threads (there are 3 helper threads used currently, right?). The ones that are left will still need to join the marshalling apartment though, so this patch will still be necessary. > I think we discussed about using a field in the RPCMESSAGE reserved > for the RPC runtime (which is what we are emulating here). I don't > think any other reworking is required. I couldn't see at the time how that'd work: the problem is we need to keep track of information across arbitrary application stack frames, ie IRpcStubBuffer::Invoke -> InstallShield code -> proxy call -> pipe?!? We can't transfer information across the InstallShield code without using a TLS slot. In native DCOM this doesn't matter as the proxy doesn't need to use the same pipe that the RPC came in from, it'll be using a different connection. In our current code, that won't work as the original caller can only re-enter from RPCs incoming on the same pipe it originally called out on. Native RPC doesn't use a thread per stub manager, and each outgoing call that could re-enter spawns another thread that dispatches incoming RPCs ad-infinitum. Ugh, that's clear as mud I know. The issue is that our threading is wrong: we need more instances of the threads so re-entrancy works correctly. Before we change anything in this area then we need: a) the unit tests you wrote to be in CVS b) more tests for out of process COM and out of process call re-entrancy Once we can check the state of the code with more than just the random InstallShields we have, then I think it'll be OK to rework the threading/pipe management so thread-affinity works correctly. > The main changes I object to are adding more fields to structures that > I was previously pruning of hacks. While we have any helper threads that don't correspond exactly to what native DCOM does they'll need to enter the original apartment, I don't see any way around that. Simply not making them join will mean the current code is not only hacky but also wrong, which goes back to the first point. During the transition to real DCOM some hacks will be needed to support the original infrastructure, it's unavoidable. They can and will be removed as the rest of the code allows it. We're both keen to get correct code as soon as possible, but this is a long term project and we want to keep disruption to a minimum. thanks -mike

Dec. 21, 2004