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

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

by Mike Hearn

On Mon, 2004-12-20 at 16:39 -0700, 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'm afraid that's a bit vague, there are still lots of problems with InstallShield 6 we know about. The patch I posted for me makes the FashionCam01 installer start up and run to completion again when given a native stdole32.tlb file, ie it's the same state it was after Marcus finished his initial work at least for the InstallShield I tried. All the InstallShields I've seen so far go through the same basic steps DCOM-wise, though as Rob notes they are also all unique. Native OLE should still work - is this the REG_EXPAND_SZ issue Bill mentioned? What exactly is this issue?

Dec. 21, 2004

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

by Robert Shearman

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? > 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

Dec. 21, 2004

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

by Robert Shearman

Mike Hearn wrote: >On Mon, 2004-12-20 at 17:56 +0000, Robert Shearman wrote: > > >>Sorry Mike, but we want to *remove* the current hacks for the >>RPC-runtime emulating named pipe code, not adding more. >> >> > >Yes, of course, but we also want to keep the code in CVS in a roughly >working situation. As it is, the code is guaranteed to crash with all >InstallShields (or indeed any program that uses out of process COM). If >Alexandre was to do a new tarball release tomorrow that's a lot of users >who are now inconvenienced. > > 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. >Currently table marshalling isn't implemented, nor is thread affinity. >They're not 5-line patches either. They are on the todo list though and >when they're done we can redo the threading to work more like native and >remove the hacks. > > 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. Thread affinity (dispatching calls to the right apartment) should also be quite easy to do, although not a 5-line patch, of course. >IIRC the patch I wrote for thread affinity at the start of the summer >was never submitted precisely because it used a hack to ensure the >thread could find its wine_pipe again (a TLS slot/stack thing). I think >for thread affinity to work correctly we need to at least rework how >pipes and threads interact, maybe even switch it on top of the RPC >runtime transports entirely so re-entrancy works correctly. > > 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. >The patch really isn't as big as it looks, there are some formatting >changes in there and some renaming+commenting. > > The main changes I object to are adding more fields to structures that I was previously pruning of hacks. Rob

Dec. 21, 2004

Re: Approving of the WINEprobe initiative

by Christian Britz

Scott Ritchie schrieb: >So, yes, I support the PortWINE initiative. :) > > PortWine would be a GREAT name, english or german! :-) Liebe Schwaben, please consider this... ;-) BTW: I would be very happy if our community could give them some "official" seal or mention... Especially because they seem to have some focus on the public sector. Did you know that the public sector is already the leading free software user in germany? Sometimes public authorities aren't that bad at all... ;-) Regards Christian Hessen ;-) Germany

Dec. 21, 2004

Re: Approving of the WINEprobe initiative

by Brian Vincent

On Mon, 20 Dec 2004 19:13:00 +0100, David Gümbel <david.guembel(a)itomig.de> wrote: > Jep, 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 I saw that reference later in the email. That does make sense and I guess WINEprobe is a good name. Not so good when said in English, but then again that doesn't really matter. Puns are fun. I'm sure there's plenty of English words that don't sound so good in German :) By the way, didn't we standardize on "Wine" rather than "WINE" a few years ago? Would "WineProbe" be more appropriate? So as far as official endorsement.. I'm sure someone in the Wine community will speak up if they disagree with anything. (Conversely, they won't speak up if they agree.) The three projects you mentioned all sound great and they're things that really should be worked on. So in the sense that stuff should get done - I think we all want that. That leads up to your question of whether the Wine community approves of the initiative? Well.. I'm not qualified to answer that question. If you do contribute to Wine, we'll gladly add you to our acknowledgements page ( http://www.winehq.org/site/acknowledgement ). Then you can say things in press releases like, "WRS, an acknowledged Wine contributor, ....." Anyone disagree with that idea? -Brian Vincent

Dec. 21, 2004

Re: [LOSTWAGES]New short About blurb on the Front Page

by Scott Ritchie

http://www.winehq.org/hypermail/wine-patches/2004/12/0343.html Is there a reason why this little update hasn't been committed? I think it makes the front page a bit more user-friendly, as well as updating some of the links. Thanks, Scott Ritchie

Dec. 21, 2004

My "Helping Applications Work" Guide

by Scott Ritchie

I've recently finished up my "helping applications work" guide. It's meant to be something an end user with a problem application can read, and if he has the will to learn how to help. 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. I've also sent it to wine-patches, but as I said nothing yet links to it. Thanks, Scott Ritchie ----helping_applications.template---- <h1>How to help get applications working in Wine</h1> <p>If you want to help get an application working in Wine, the first thing you should do is register yourself in the applications database and use one of your votes to indicate that you'd like more effort to be spent on the application. Every once in a while, a wine developer will finish a project and look for something to do - combing through the higher voted apps to find one that people need work on is a great way to spend one's time and fill up a todo list.</p> <p>If the application that you want working is not listed in the applications database, there is an easy to use form available for you to add it.  If the application is in the database, but lacks a maintainer you should consider becoming one. If you are familiar with wine and have a desire to test the application and help get or keep it working, please apply by clicking the link in the application's page. Each application should have a supermaintainer, and, if different versions of the application are substantially different (such as in Internet Explorer), each subversion should have a maintainer. Please don't feel deterred by the need to apply to become a maintainer - the application form is largely a formality to prevent abuse and we can virtually guarantee your acceptance.</p> <p>If you are the developer or publisher of the application, you obviously have a very big incentive to help get your application working under wine. Fortunately, there are many options available to you other than reporting bugs and hoping someone will fix them. By far the easiest way is to simply send free copies of your software to wine developers and hope they'll take an interest in getting it working. You'd be amazed how effective this approach can be, particularly for games. 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. The most direct method, however, is to help develop wine itself and contribute code directly, which is exactly what Corel did for WordPerfect several years ago. In any case, making a post on the wine developers <a href="http://www.winehq.org/site/forums">email list</a> can go a long way. <h2>If your application doesn't work:</h2> <p>If your application experiences problems in a particular area, or fails to even run at all, there are a number of steps you can take to help us. The most important thing is to find out where exactly the application is failing. To diagnose application problems, the first step is to run the program from the console using wine, rather than from a gui shortcut. This will allow wine to output error messages to the console, the understanding of which are key to solving the problem and getting the application to work.</p> <p>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. When this occurs, you can try using native (non-wine) DLL files in place of Wine's builtin ones. Check the application database page for the program. There may be special configuration options or instructions for installing native DLL files there that you can try to get the application working. For further configuration help, please see the <a href="http://www.winehq.org/site/docs/wine-user/running">Running Wine</a> section of the User Guide.</p> <p>If the application still doesn't work, it's probably due to a bug or deficiency in Wine and we'd like to hear about it. Please see the <a href="http://bugs.winehq.org/">reporting bugs</a> page for instructions on how to best report bugs with applications.</p> <h2>If your application does work, but with some difficulty:</h2> <p>Sometimes, applications run under wine but they don't function quite as smoothly as they do in windows. They may have display errors, a feature may be broken, or they may run unusually slow. These applications should receive a lower rating from their maintainers of between 2 and 4 stars in the Application's Database, depending on the degree of difficulty encountered.</p>  <p>If you have found a way to make an application work that is more complicated than simply installing it, please share that information by posting on the application's page in the database. If you are the maintainer for the application, please post the instructions in a "howto," which will appear inside green bars at the top of the application's page.</p> <h2>If your application used to work, but has since broken in a new version of wine:</h2> <p>Wine is a large and complex project, composed of many files written by different authors. Sometimes, an attempt to change a file and expand support for one application will unexpectedly cause another application to stop functioning. These changes are known as "regressions", and they are unfortunately sometimes found in the wine source code because the author of a patch that causes a regression is quite simply unaware of it. Since the wine developers can't possibly test every application with every patch, we have to rely on the community to inform us of when regressions occur so that the problem can be easily identified and ultimately fixed. Without community involvement, regressions can go unfixed for potentially very long periods of time.</p> <p>If your application has experienced a regression, please try and provide us with as much information as you can about when and how it broke. This allows us to isolate the exact thing we screwed up in the code and provide a fix. Please provide as much as you know about which version of wine worked, and which version didn't, including the version number and how you installed it (from source, binary packages, etc.) Finally, please post these things in the Application Database page for the app.</p> <p>If you wish to be extremely helpful, you can try to isolate the exact patch which broke your application. This takes quite a bit of time and effort, but it is quite simply the best way to get your application working again. When it comes to fixing regressions, the only thing more helpful to the wine developers than knowing exactly which patch caused a regression is receiving a fix for the patch itself. For help with isolating problem patches, please see the documentation on <a href="http://www.winehq.org/site/docs/wine-devel/x1375">regression testing</a>.</p>

Dec. 21, 2004

Re: Approving of the WINEprobe initiative

by Scott Ritchie

On Mon, 2004-12-20 at 16:20 +0100, David Gümbel wrote: > 1) At the option of the respective software vendor whose product we'll be > analyzing for WINE compatibility, Application Database Entries will be > maintained by us once a software product has been analyzed for its > compatibility with WINE. > Excellent. AppDB seems to be almost ready, and some dedicated developer maintainers would be an amazing thing. > 2) Reports of successful porting or migration projects will be given back to > the community as success stories. My colleage is already working on merging > some success stories supplied by third parties (see [6]). > > 3) WRS has offered to help out in hosting the WINE developers conference > Wineconf in 2005 in the Stuttgart area[7]. > > I'd love to head out to Stuttgart if someone would be willing to fly me there. As it stands I can only really afford to go on long roadtrips about the United States. Either way, I'm probably not that important. > If there are any questions open, please feel free to ask. > > ---------- Forwarded Message ---------- > > [1] http://www.mail-archive.com/wine-devel%40winehq.org/msg11549.html > [2] WINEprobe means be something like WINEtasting in english an maybe > "degustation de WINE" in french. I'm going to echo the sentiment that WINEprobe is a horrible name in English. Frankly, when I think of probes I think of aliens or doctors doing nasty experiments on my body parts. At best, I think of a probing attack with troops on a battlefield. A better name would be the alluded to WINEtasting mentioned here. It may be a tad cliche, but at least it doesn't drum up horrible images. However, I think we have an opportunity to make a really crafty and invigorating name here. My personal favorite would be to combine the concept of a "port" for software with the class of dessert wine known as "port." It would be a really delicious pun, and it would drum up the right images. So, yes, I support the PortWINE initiative. :) Thanks, Scott Ritchie scott(a)open-vote.org

Dec. 21, 2004

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

by tony_lambregts＠telusplanet.net

Mike Hearn wrote: > On Mon, 2004-12-20 at 17:56 +0000, Robert Shearman wrote: > >>Sorry Mike, but we want to *remove* the current hacks for the >>RPC-runtime emulating named pipe code, not adding more. > > > Yes, of course, but we also want to keep the code in CVS in a roughly > working situation. As it is, the code is guaranteed to crash with all > InstallShields (or indeed any program that uses out of process COM). If > Alexandre was to do a new tarball release tomorrow that's a lot of users > who are now inconvenienced. > > Currently table marshalling isn't implemented, nor is thread affinity. > They're not 5-line patches either. They are on the todo list though and > when they're done we can redo the threading to work more like native and > remove the hacks. > > IIRC the patch I wrote for thread affinity at the start of the summer > was never submitted precisely because it used a hack to ensure the > thread could find its wine_pipe again (a TLS slot/stack thing). I think > for thread affinity to work correctly we need to at least rework how > pipes and threads interact, maybe even switch it on top of the RPC > runtime transports entirely so re-entrancy works correctly. > > The patch really isn't as big as it looks, there are some formatting > changes in there and some renaming+commenting. > > thanks -mike > > > 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. If there is anyway I can help this process I please tell me. -- Tony Lambregts.

Dec. 20, 2004

Re: Make winetest.exe detect if it is running on a visible desktop. Now without the linewrap.

by Ferenc Wagner

Jakob Eriksson <jakov(a)vmlinux.org> writes: > Now without the linewrap. I hate to say this, but it's still wrapped... :( -- Feri.

Dec. 20, 2004

Janitorial: HeapFree of NULL

by Michael Stefaniuc

Hello, there is a lot (my attached smatch script found 234 occurences) of code like if (this) HeapFree(GetProcessHeap(), 0, this); HeapFree(GetProcessHeap(), 0, that); which is redundant because after Win2000 (if i can trust the comment in RtlFreeHeap) freeing a NULL pointer isn't an error. I've checked it Win2000 and can confirm that. I've also checked Win95 and Win98 and both don't crash when HeapFree'ing a NULL but they return an error and SetLastError to 212 "ERROR_LOCKED". In the above code the return code of HeapFree isn't checked so this wouldn't matter if somebody would run the Wine code on that Win versions. So i propose to shorten that code to HeapFree(GetProcessHeap(), 0, this); HeapFree(GetProcessHeap(), 0, that); I've done this already for the wininet dll (see patch to wine-patches) and if it gets accepted i'll take care of the rest. Advantages: - less (redundant) code - more pleasant to the eye - for the wininet.dll it saves 1.1kB (FC2, gcc-3.3.3-7) in the generated code (ok, the wininet.dll.so is 1.6 MB but still) Disadvantages: - if the pointer is NULL it takes longer for that code path. But i don't think it matters cause this happens mostly only on the (unlikely) error path. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 20, 2004

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

by Mike Hearn

On Mon, 2004-12-20 at 17:56 +0000, Robert Shearman wrote: > Sorry Mike, but we want to *remove* the current hacks for the > RPC-runtime emulating named pipe code, not adding more. Yes, of course, but we also want to keep the code in CVS in a roughly working situation. As it is, the code is guaranteed to crash with all InstallShields (or indeed any program that uses out of process COM). If Alexandre was to do a new tarball release tomorrow that's a lot of users who are now inconvenienced. Currently table marshalling isn't implemented, nor is thread affinity. They're not 5-line patches either. They are on the todo list though and when they're done we can redo the threading to work more like native and remove the hacks. IIRC the patch I wrote for thread affinity at the start of the summer was never submitted precisely because it used a hack to ensure the thread could find its wine_pipe again (a TLS slot/stack thing). I think for thread affinity to work correctly we need to at least rework how pipes and threads interact, maybe even switch it on top of the RPC runtime transports entirely so re-entrancy works correctly. The patch really isn't as big as it looks, there are some formatting changes in there and some renaming+commenting. thanks -mike

Dec. 20, 2004

Re: Approving of the WINEprobe initiative

by David Gümbel

On Montag 20 Dezember 2004 18:41, Brian Vincent wrote: > <david.guembel(a)itomig.de> wrote: > > - as my colleague Stefan Munz has already pointed out recently[1] on > > this list, Wirtschaftsförderung Region Stutgart GmbH (WRS) and us > > (ITOMIG) are launching an initiative called WINEprobe[2]. Its goal is > > to make local software vendors aware of the potential bussiness > > opportunity in a WINE-based port or a WINE/Linux version of their > > software. > > Just curious, what is ITOMIG? We're a local company specializing in compatibility analyses of Windows software with Linux/Wine. Our clients are mostly from the administrative and the public sector. > > In order to make the WINEprobe initiative beneficial for the WINE > > project as much as possible, three things are in the making: > > WINEprobe is an.. er.. interesting name. Why did you choose it? From > a marketing perspective, it doesn't seem like a good name. In > general, the word "probe" doesn't exactly give a warm, fuzzy feeling > or generate excitement. Is this a translation of a German word that > sounds better? Jep, 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 > It sounds like you guys are interested in Winelib stuff. I'm sure > you've investigated the pros/cons of that. Did you notice the Winelib > documentation is very outdated? Would you guys want to tackle > updating it? In case this fits into a real project (say, porting some legacy application) we're doing e.g. in line with the WINEprobe initiative, yeah - why not. In general, we always try to let flow back as much as possible to the respective OSS projects whose software we're using. Cheers, David

Dec. 20, 2004

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

by Robert Shearman

Mike Hearn wrote: >This patch makes InstallShield work again, and should let you get >further Bill. > >- Ensure all intermediate threads join the original apartment >- Make the listener thread fully apartment scoped (one per apt not per > process) >- Improve "already have mid" error message >- Rename _StubReaderThread to stub_dispatch_thread >- Improve tracing > > Sorry Mike, but we want to *remove* the current hacks for the RPC-runtime emulating named pipe code, not adding more. The correct approach for the crash in _LocalServerThread is to use table-strong marshaling once and then copy the contents of the stream to the pipe for each iteration in the loop, instead of marshaling each time. The correct approach for the crash in _StubReaderThread is to make it execute in the correct apartment - either by sending a window message to the STA window or by joining the MTA. I believe you had a patch for this in July or August when we last worked on this. Rob

Dec. 20, 2004

Re: Approving of the WINEprobe initiative

by Brian Vincent

On Mon, 20 Dec 2004 16:20:50 +0100, David Gümbel <david.guembel(a)itomig.de> wrote: > - as my colleague Stefan Munz has already pointed out recently[1] on this > list, Wirtschaftsförderung Region Stutgart GmbH (WRS) and us (ITOMIG) are > launching an initiative called WINEprobe[2]. Its goal is to make local > software vendors aware of the potential bussiness opportunity in a > WINE-based port or a WINE/Linux version of their software. Just curious, what is ITOMIG? > In order to make the WINEprobe initiative beneficial for the WINE project as > much as possible, three things are in the making: WINEprobe is an.. er.. interesting name. Why did you choose it? From a marketing perspective, it doesn't seem like a good name. In general, the word "probe" doesn't exactly give a warm, fuzzy feeling or generate excitement. Is this a translation of a German word that sounds better? It sounds like you guys are interested in Winelib stuff. I'm sure you've investigated the pros/cons of that. Did you notice the Winelib documentation is very outdated? Would you guys want to tackle updating it? -Brian Vincent

Dec. 20, 2004

Re: OpenSCManager() bug

by Ivan Leo Puoti

>Hello, > >initially i tested this stuff under XP and it raised exception if lpDatabaseName >is invalid pointer. But after you noticed the bug i run the test under 2000 and >it has been returned ERROR_NOACCESS. > >Both versions return ERROR_INVALID_NAME if lpDatabaseName is empty string. > >I think the patch should look like this: In Age of Empires 2 lpDatabaseName is just an empty string, so I've sent a patch to wine-patches that allows the database name to be '\0'. Ivan.

Dec. 20, 2004

Approving of the WINEprobe initiative

by David Gümbel

Hello everybody, - as my colleague Stefan Munz has already pointed out recently[1] on this list, Wirtschaftsförderung Region Stutgart GmbH (WRS) and us (ITOMIG) are launching an initiative called WINEprobe[2]. Its goal is to make local software vendors aware of the potential bussiness opportunity in a WINE-based port or a WINE/Linux version of their software. WRS is quite committed as far as Open Source is concerned[3], and is pushing OSS in the region since quite a time. It has co-organized, among others, the KDE World Summit 2004 in Ludwigsburg near Stuttgart[4]. The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) [5], ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. (You can find a description of WRS at the bottom of this mail.) In order to make the WINEprobe initiative beneficial for the WINE project as much as possible, three things are in the making: 1) At the option of the respective software vendor whose product we'll be analyzing for WINE compatibility, Application Database Entries will be maintained by us once a software product has been analyzed for its compatibility with WINE. 2) Reports of successful porting or migration projects will be given back to the community as success stories. My colleage is already working on merging some success stories supplied by third parties (see [6]). 3) WRS has offered to help out in hosting the WINE developers conference Wineconf in 2005 in the Stuttgart area[7]. Mr. Schmid from WRS has asked me (please see the mail below) to provide some information about this initiative to the WINE community. He thinks (and I agree ;) that it would help us a great deal in making the campaign a success if the WINE community somehow "officially" (as official as a community can be :) approved of this initiative. So my question, on behalf of Mr. Schmid, is simply if there are objections against us saying that this initiative is approved of by the WINE community? As an important sidenote, I permit myself to emphasize that all of our above mentioned efforts (1-3) to support the WINE project and its community are fully independent of the answer of this question. Most particularily, the hosting offer stands, and the commitment there won't be lowered if the WINEprobe is not approved of by the community. However, I feel that a successful WINEprobe will be a benefit for the WINE project as well. If there are any questions open, please feel free to ask. Cheers, David ---------- Forwarded Message ---------- Subject: AW: Update on WRS offer & Stuttgart University Date: Montag 20 Dezember 2004 14:46 From: "Hans-Ulrich Schmid" <hans-ulrich.schmid(a)region-stuttgart.de> To: David Gümbel <david.guembel(a)itomig.de> Dear Mr. Gümbel, as you know, ITOMIG and Stuttgart Region is planning to start a new initiative for small and medium software companies called "WINEprobe". "WINEprobe" will help these companies to learn more about the WINE-compatibility of their software products. It would be very helpful, if you can ask the WINE-community to support this new initiative officially. The hosting offer of the Stuttgart Region will not be affected by any way of the decision of the community in the point of supporting the "WINEprobe" or not. Can you please forward this mail to the community and tell them some more about the background of "WINEprobe" Best regards Hans-Ulrich Schmid Wirtschaftsförderung Region Stuttgart GmbH Stuttgart Region Economic Development Corporation FIR_st - Forum IT-Region Stuttgart Friedrichstr. 10 70174 Stuttgart www.first.region-stuttgart.de www.opensource.region-stuttgart.de www.competenzatlas.de www.region-stuttgart.de Tel ++49.711.22835 - 27 Tel mobil ++49.172.7310463 Fax ++49.711.22835 - 55 ------------------------------------------------------- ------------------------------------------------------- WRS description: The Stuttgart Region Economic Development Corporation (WRS) is - founded to provide services to industry and communities in the field of economic development - a subsidiary of the administrative body of the larger Stuttgart Region - provides marketing for the Stuttgart Region - assists in cluster management of specific industries - advises and assists companies during the search for available sites and buildings In the context of our initiative "Open Source Region Stuttgart" http://opensource.region-stuttgart.de the WRS supports conferences and meetings of Open Source projects of various aspects when held in the Stuttgart Region. For example the WRS is co-organizer of the KDE Community World Summit 2004 in Ludwigsburg near Stuttgart http://conference2004.kde.org/ . The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) http://2005.guadec.org/papers.html , ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. ------------------------------------------------------- [1] http://www.mail-archive.com/wine-devel%40winehq.org/msg11549.html [2] WINEprobe means be something like WINEtasting in english an maybe "degustation de WINE" in french. [3] See http://opensource.region-stuttgart.de/ (.de only, sorry) [4] http://conference2004.kde.org/ [5] http://2005.guadec.org/papers.html [6] http://www.mail-archive.com/wine-devel%40winehq.org/msg11630.html [7] http://www.winehq.org/hypermail/wine-devel/2004/11/0647.html

Dec. 20, 2004

Re: TopLevelWindow Maximize

by Katia Maculan

Dmitry Timoshkov wrote: >"Katia Maculan" <katia.maculan(a)isis-papyrus.com> wrote: > > > >>+ switch (message) >>+ { >>+ case WM_SHOWWINDOW: >>+ case WM_SIZE: >>+ DefWindowProc(hWnd, message, wParam, lParam); >>+ PostMessage (hWnd, WM_PAINT, 0, 0); >> >> > >If you wish to schedule a WM_PAINT message you have to invalidate >a window. > > > You are right but with an InvalidateRect a WM_PAINT is not generated I think for another problem. Katia -- Katia Maculan Developer ISIS Papyrus Italy Srl Tel: (+39) 0125 6455400 Fax: (+39) 0125 6455150 E-mail: katia.maculan(a)isis-papyrus.com Info: info(a)isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com

Dec. 20, 2004

Re: OpenSCManager() bug

by Alexander Yaworsky

Hello, initially i tested this stuff under XP and it raised exception if lpDatabaseName is invalid pointer. But after you noticed the bug i run the test under 2000 and it has been returned ERROR_NOACCESS. Both versions return ERROR_INVALID_NAME if lpDatabaseName is empty string. I think the patch should look like this: @@ -750,6 +750,11 @@ if( lpDatabaseName ) { + if( IsBadStringPtrW( lpDatabaseName, -1 ) ) + { + SetLastError( ERROR_NOACCESS ); + return NULL; + } if( strcmpiW( lpDatabaseName, SERVICES_ACTIVE_DATABASEW ) == 0 ) { /* noop, all right */ On the other hand i think that all this stuff is a kind of masturbation. When i implemented this, i used some tests (i'm going to put them into shape of unit tests) to investigate the real behaviour. The last patch establishes that behaviour replacing fixme that was an eyesore, but in reality the database name is not used and IMO will never be used. Ivan Leo Puoti wrote: > This patch http://cvs.winehq.org/patch.py?id=14769 had caused a problem with Age > of Empires. The game uses a copy protection system that is installed as a > service, before your patch, the service tried to load the copy protection driver > (This fails, but that's another story), after your patch wine goes straight to > the debugger after calling OpenSCManager. I added a trace and found that this > code is executed > { > FIXME("ERROR_INVALID_NAME"); > return NULL; > } > and causes the crash. The value of lpDatabaseName that AoE passes to the > function is 1; also according to MSDN > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba… > lpDatabaseName can be NULL, and in this case SERVICES_ACTIVE_DATABASE is opened. > As it's late here the only idea I get at the moment is to print the value as a > FIXME or ERR or whatever, and not return NULL, as this doesn't appear to be the > correct behavior. As you've implemented this stuff and I don't know much about > it I would like to know what you think.

Dec. 20, 2004

safedisc

by Ivan Leo Puoti

The attached patch is the first step towards supporting safedisc, it adds code sent from Marcus a few months ago to the current dlls/ntdll/virtual.c It allows us to successfully load the secdrv.sys file into memory. It has been tested with the copy of safedisc that comes with Age of Empires 2. I've just checked that it compiles without warnings and loads the file, there may be room for improvement, so I'm posting it here for review. The next step will be to merge Marcus's implementation of ntloskrnl.exe, that is needed because safedisc imports some functions from that file. Ivan.

Dec. 20, 2004

Re: [AppDB] big AppDB refactoring

by Jonathan Ernst

Le samedi 18 décembre 2004 à 19:31 -0500, Chris Morgan a écrit : > I looked the patch over, you move include/user.php to include/classes/user.php > but you didn't just move the class, you moved the class AND functions that > call in to the user class. Why bother separating things into functions and > classes if this isn't even the case in the patch? > I moved user into classes because it is a class and removed functions that are not method of this class into another library. A class is a class and shouldn't contain other code I think. See: http://www.phpfreaks.com/tutorials/35/1.php for example Don't you ever tried to do $current->loggedin() in the past before to see that loggedin() was not a method ? > I wish we could have at least talked about this patch before you went through > the effort to make these changes. I can't see any reason why we should > separate functions and classes. Right now the name of the php file indicates > what the contents of the file are. Lets talk about where we are going with The names don't tell you if it's a class or not and are not clear enough in my opinion. It's no wonder why many things in the code are made "by hand" while functions already exist in the include directory (sql queries, things in includes/html are barely used, etc). Some files have an _inc suffix which is redundant as they are in a directory named include... There are also too many files and maybe we could improve this situation (people not using or finding usefull functions) by reorganising it (that was the purpose of my patch and it's huge because deleting files and adding new files make diffs huge). > this and look at some examples of how these changes would improve things > before we decide to make them. I thought that the include directory was not exactly well organised; you have files in it that have different purposes. Some are just plain includes (headers, footers), others are classes and others provide functions. Last but not least some mix classes and functions and you even have some files in / that provide usefull (sometimes duplicated functions). As to discuss it you know that it's hard for me to be woken up at nights to discuss every thing so I thought I'll simply do the changes, test it the whole day (and be confident that it makes much more good than bad and that everything works just the same or better) I think that we could decide alltogether if you think my arguments for reorganising the includes/functions is valid or not and if it is we could start moving it. Finally I saw you committed my config changes and I'm glad you saw that it might be an improvement over the current situation. I'll send a new patch that _only_ takes advantage of the new config file. Thanks for your time and efforts, Jonathan

Dec. 19, 2004

Re: [AppDB] big AppDB refactoring

by Chris Morgan

I'd feel bad if this issue hadn't come up a few times in the past. Sending in large patches that do multiple things is silly. Even worse is that these are fundamental changes to where things are located but we haven't even decided there is a problem with how things are now or even whether things are better after these changes. I looked the patch over, you move include/user.php to include/classes/user.php but you didn't just move the class, you moved the class AND functions that call in to the user class. Why bother separating things into functions and classes if this isn't even the case in the patch? I wish we could have at least talked about this patch before you went through the effort to make these changes. I can't see any reason why we should separate functions and classes. Right now the name of the php file indicates what the contents of the file are. Lets talk about where we are going with this and look at some examples of how these changes would improve things before we decide to make them. Chris On Saturday 18 December 2004 3:16 pm, Jonathan Ernst wrote: > Hello, > > I certainly agree that I could have separated apidb->appdb changes from > the rest (but replacing it is trivial and is functionnaly equivalent), > but I can't seriously make one patch for each file moved as it'll > require to patch every dependent files for each move. > > The files in / import files in /include if I move one file from /include > to /include/classes I have to patch all files. > > Then I have to wait until the patch is commited which will take one day > because of timezones. > > Then I have to move the second file and re-change every single file that > includes it. and so on at least 25 times (because there are 25 moved > files) without counting the code moving between includes. > > I will _try_ to split the patch in three or four smaller patches and I > hope we can find a way to make it in as it would allow for more > interesting (and smaller ;-) ) changes later. > > As I'm not an expert, if you have advices on how to split it more > efficiently I'm all open as you know. > > See you, > > > > > > > <gack> you _can't_ be serious. > > > - One patch to do one thing. For example each of the following should > > their own patch. > > > > Change apidb_header() and apidb_footer() to appdb_header() and > > appdb_footer() Change apidb_fullurl() to appdb_fullurl > > Move include/tableve.php to include/classes/tableve.php > > Move include/application.php to include/classes/application.php > > ... > > > > I know you probably will end up sending more than a dozen patches that > > way. However, I can't approve of a wholesale change, like this, in one > > go. > > > > </gack> > > > > The changes you propose are good ones. Just break them down. > > > > -- > > > > Tony Lambregts

Dec. 19, 2004

Loading a .dll.so from current directory

by Frank Richter

Hi, I would like to load a .dll.so from the current directory, and I wonder what's the best way to accomplish this... I tried to set WINEDLLPATH, but it doesn't seem to have an effect (the .dll.so is still only tried to be loaded from /usr/lib, as I can see from the trace:module output). The .dll.so is loaded from a .dll that in turn is called by rundll32... could I perhaps "patch" the DllOverrides for rundll32 in the registry? -f.r.

Dec. 19, 2004

AppDB update (refactoring and new ideas)

by Jonathan Ernst

Hello, I made a huge patch that (IMHO) cleans up the code structure of the AppDB and as a side effect, fixes most remaining global vars bugs. If this patch can be added tonight I'll then improve and fix the screenshot code (it works, but sometimes there are problems with backslashing the image content). I found better ways to store images in mysql but I think it would be even better to put it on the serveur in /data/screenshots/queued/ they'll have an integer name (appDataQueue table's id) and the directory listing must not be readable. I plan to change the way thumbnails are done. On the fly image generation can be very time consumming and if there are many users in the futures I think we could achieve much better performances using one-time thumbnails generation. As you can see I added in the config file width and height parameters for screenshots so that the algorithm will look like this: do we have a thumbnail of the requested size for the requested imageId ? - if yes, serve the image - if no create a file /data/screenshots/thumbnails/$imageid_$width_ $height.$ext This solves many problems: 1) less cpu demanding 2) if we change the file size in the config file, new thumbnails will be made upon request and someone can clean up the thumbnail directory using rm *_oldWidth_oldHeight.* 3) if two people submit two pictures with the same name (screenshot.png for example) it won't conflict as the id of the table is used 4) when a screenshot is accepted by an administrator or maintainer we just copy the file from /data/queued/screenshots and then delete it If you do think it's clean like this, i'll work on it asap but then please ask the following to Jeremy if you see him (even if it breaks the screenshot function for some hours I think it's not a big issue): 1)create /data/queued/screenshots and /data/queued/screenshots/thumbnails directories (they have to be writable by the php process) 2)after making sure that no appdata is pending in the admin, issue the following sql requests: drop table if exists appDataQueue; /* * links to screenshots and other stuff waiting to be accepted */ create table appDataQueue ( queueid int not null auto_increment, appId int not null, versionId int default 0, type enum('image', 'url'), description text, url varchar(255), userId int not null, submitTime timestamp, key(queueid), index(appId), index(versionId) ); Thanks a lot for everything, hope you like the patch altough it's huge (but it works and I couldn't make it much smaller as there are quite deep implications when moving things around)

Dec. 18, 2004

Re: [AppDB] big AppDB refactoring

by Jonathan Ernst

Hello, I certainly agree that I could have separated apidb->appdb changes from the rest (but replacing it is trivial and is functionnaly equivalent), but I can't seriously make one patch for each file moved as it'll require to patch every dependent files for each move. The files in / import files in /include if I move one file from /include to /include/classes I have to patch all files. Then I have to wait until the patch is commited which will take one day because of timezones. Then I have to move the second file and re-change every single file that includes it. and so on at least 25 times (because there are 25 moved files) without counting the code moving between includes. I will _try_ to split the patch in three or four smaller patches and I hope we can find a way to make it in as it would allow for more interesting (and smaller ;-) ) changes later. As I'm not an expert, if you have advices on how to split it more efficiently I'm all open as you know. See you, <gack> you _can't_ be serious. > > - One patch to do one thing. For example each of the following should their own > patch. > > Change apidb_header() and apidb_footer() to appdb_header() and appdb_footer() > Change apidb_fullurl() to appdb_fullurl > Move include/tableve.php to include/classes/tableve.php > Move include/application.php to include/classes/application.php > ... > > I know you probably will end up sending more than a dozen patches that way. > However, I can't approve of a wholesale change, like this, in one go. > > </gack> > > The changes you propose are good ones. Just break them down. > > -- > > Tony Lambregts > > >

Dec. 18, 2004

Re: [AppDB] big AppDB refactoring

by tony_lambregts＠telusplanet.net

Jonathan Ernst wrote: > This patch is a big refactoring of the AppDB. Some files have been > moved and renamed, others were simply deleted and many where fixed and > improved. No functional differences (apart the fixed global vars). > > *The configuration (config.inc.php) has to be updated on the live server* > > CHANGELOG: > - moved functional code out of procedural code > - moved functional code out of object oriented code > - moved classes in /include/classes/ > - moved functions libraries in /includes/functions/ > - deleted some no more needed files (content was duplicate or included in other files) > - created a library for bugzilla related functions > - moved some code from one library to another library (db related in /include/db.php, etc.) > - improved the config file (using constants, ability to specify new parameters that would make it very easy to integrate the appdb on another site like ReactOS as they can replace references to winehq and bugs.winehq.org for example) > - the debug parameter of the config file is now taken into consideration in the code (function isdebugging() has been improved) > - fixed some obvious global vars bugs when encountered (so that the help system re-works and most broken admin functions are back) > - replaced apidb occurences with appdb as it's the name of the application > - replaced $apidb_root occurences with BASE constant because both were used and had the same value (so no more glbal $apidb_root needed) > - updated TODO and CODING_STANDARD regarding these changes > - overall improved security (because of global vars and using constants for the config so that it can't be changed using php injection) > > Files added: > - include/classes/application.php > - include/classes/menu.php > - include/classes/screenshot.php > - include/classes/tableve.php > - include/classes/category.php > - include/classes/query.php > - include/classes/session.php > - include/classes/user.php > - include/functions/appdb.php > - include/functions/date.php > - include/functions/maintainer.php > - include/functions/rating.php > - include/functions/util.php > - include/functions/banner.php > - include/functions/db.php > - include/functions/pn_buttons.php > - include/functions/sidebar_admin.php > - include/functions/vote.php > - include/functions/bugzilla.php > - include/functions/help.php > - include/functions/sidebar_login.php > - include/functions/comments.php > - include/functions/html.php > - include/functions/query.php > - include/functions/sidebar.php > > > Files deleted: > - include/appbyvendor_inc.php > - include/appdb.php > - include/application.php > - include/appversion_inc.php > - include/banner.php > - include/category.php > - include/comments.php > - include/db.php > - include/html.php > - include/maintainer.php > - include/menu.php > - include/parsedate.php > - include/pn_buttons.php > - include/qclass.php > - include/query_inc.php > - include/rating.php > - include/session.php > - include/sidebar.php > - include/sidebar_admin.php > - include/sidebar_login.php > - include/tableve.php > - include/user.php > - include/util.php > - include/vote.php > > File changed: > - CODING_STANDARD > - TODO > - account.php > - addcomment.php > - appbrowse.php > - appdbStats.php > - appsubmit.php > - appview.php > - bugs.php > - commentview.php > - deletecomment.php > - edituser.php > - index.php > - maintainerdelete.php > - maintainersubmit.php > - noteview.php > - preferences.php > - screenshots.php > - search.php > - stdquery.php > - support.php > - updaterating.php > - updatevote.php > - vendorview.php > - votestats.php > - admin/addAppFamily.php > - admin/addAppNote.php > - admin/addAppVersion.php > - admin/addCategory.php > - admin/addVendor.php > - admin/adminAppQueue.php > - admin/adminCommentView.php > - admin/adminMaintainerQueue.php > - admin/adminMaintainers.php > - admin/deleteAny.php > - admin/editAppFamily.php > - admin/editAppNote.php > - admin/editAppOwners.php > - admin/editAppVersion.php > - admin/editBundle.php > - admin/editCategory.php > - admin/editVendor.php > - admin/index.php > - admin/adminAppDataQueue.php > - help/index.php > - include/config.php.sample > - include/header.php > - include/incl.php > - include/query_users.php > <gack> you _can't_ be serious. - One patch to do one thing. For example each of the following should their own patch. Change apidb_header() and apidb_footer() to appdb_header() and appdb_footer() Change apidb_fullurl() to appdb_fullurl Move include/tableve.php to include/classes/tableve.php Move include/application.php to include/classes/application.php ... I know you probably will end up sending more than a dozen patches that way. However, I can't approve of a wholesale change, like this, in one go. </gack> The changes you propose are good ones. Just break them down. -- Tony Lambregts

Dec. 18, 2004

Re: Message Notify

by Mike Hearn

On Sat, 18 Dec 2004 08:44:46 -0800, Duane Clark wrote: > It appears to me that you have not used this email address > (m.hearn.at.signal.QinetiQ.com) for a long time, at least not for > sending to this list. If it is no longer in use, would you mind > unsubscribing it to eliminate at least this one source of viruses? Done.

Dec. 18, 2004

Re: out-of-process COM design

by Mike Hearn

On Sat, 18 Dec 2004 08:45:46 -0800, Bill Medland wrote: > 0018:trace:ole:CoMarshalInterface Using standard marshaling > 0018:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace > 0018:trace:ole:StdMarshalImpl_MarshalInterface (...,{00000000-0000-0000-c000-000000000046},...) > wine: Unhandled exception (thread 0018), starting debugger... > Backtrace: > =>1 0x40901a13 StdMarshalImpl_MarshalInterface+0xa3(iface=0x40247148, pStm=0x40247100, riid=0x42a84138, pv=0x42480180, dwDestContext=0x0, pvDestContext=0x0, mshlflags=0x0) [/home/cvswine/wine/dlls/ole32/compobj_private.h:180] in ole32 (0x42a83ff4) > 2 0x40902b07 CoMarshalInterface+0x227(pStream=0x40247100, riid=0x42a84138, pUnk=0x42480180, dwDestContext=0x0, pvDestContext=0x0, mshlFlags=0x0) [/home/cvswine/wine/dlls/ole32/marshal.c:719] in ole32 (0x42a840a4) > 3 0x40908cff CFStub_Invoke+0x2e3(iface=0x40246fe8, msg=0x42a84170, chanbuf=0x0) [/home/cvswine/wine/dlls/ole32/oleproxy.c:178] in ole32 (0x42a84154) > 4 0x4090acf2 COM_InvokeAndRpcSend+0x92(req=0x40247088) [/home/cvswine/wine/dlls/ole32/rpc.c:346] in ole32 (0x42a841ac) > 5 0x4090bc9f _StubReaderThread+0xab(param=0x40246e90) [/home/cvswine/wine/dlls/ole32/rpc.c:745] in ole32 (0x42a841c4) > 6 0x40396593 THREAD_Start+0xef(ptr=0x40246f70) [/home/cvswine/wine/dlls/kernel/thread.c:107] in kernel32 (0x42a84298) OK, the problem here is that the StubReaderThread is *also* not in an apartment. With my patch it does seem to be getting further though than with the CoInitializeEx patch, it does actually connect and do an IClassFactory::CreateInstance. As a hack you can whack a CoInitializeEx at the start of _StubReaderThread but it's wrong and will probably not work either. I think we actually need to migrate the apt through the pipe registration code so when PIPE_RegisterPipe starts the new thread, it can also join the apartment which did the original registration. This is continuing the idea of making all the implementation threads use the same apartment. I'll talk with Rob about this, as we have some DCOM work still in mid-air. thanks -mike

Dec. 18, 2004

Re: out-of-process COM design

by Mike Hearn

On Sat, 18 Dec 2004 07:46:42 -0800, Bill Medland wrote: > If I combine it with Rob's CoInitializeEx patch rather than Mike's then it executes but still fails, as follows: Try this patch. It's a modified form of Robs: Index: dlls/ole32/rpc.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/rpc.c,v retrieving revision 1.31 diff -u -p -d -r1.31 rpc.c --- dlls/ole32/rpc.c 14 Dec 2004 15:28:58 -0000 1.31 +++ dlls/ole32/rpc.c 18 Dec 2004 16:59:43 -0000 @@ -758,9 +758,10 @@ static DWORD WINAPI listener_thread(LPVO { char pipefn[200]; HANDLE listenPipe; + APARTMENT *apt = (APARTMENT *) param; - sprintf(pipefn,OLESTUBMGR"_%08lx",GetCurrentProcessId()); - TRACE("Process listener thread starting on (%s)\n",pipefn); + sprintf(pipefn,OLESTUBMGR"_%08lx%08lx", apt->oxid >> 32, apt->oxid); + TRACE("Apartment listener thread starting on (%s)\n",pipefn); while (1) { listenPipe = CreateNamedPipeA( @@ -789,13 +790,10 @@ static DWORD WINAPI listener_thread(LPVO void start_listener_thread() { - static BOOL running = FALSE; - DWORD tid; - - if (!running) - { - running = TRUE; - CreateThread(NULL, 0, listener_thread, NULL, 0, &tid); - Sleep(2000); /* actually we just try opening the pipe until it succeeds */ - } + APARTMENT *apt = COM_CurrentApt(); + + if (!apt->tid) + { + CreateThread(NULL, 0, listener_thread, apt, 0, &apt->tid); + } }

Dec. 18, 2004

Re: out-of-process COM design

by Robert Shearman

Mike Hearn wrote: >On Sat, 2004-12-18 at 07:46 -0800, Bill Medland wrote: > > >>0013:trace:ole:listener_thread Process listener thread starting on (\\.\pipe\WINE_OLE_StubMgr_0000001000000011) >> >> > >... > > > >>0009:fixme:ole:PIPE_GetNewPipeBuf Could not open named pipe \\.\pipe\WINE_OLE_StubMgr_0000001000000014, le is 2 >> >> > >Well, now we have a variation on the same problem. The apartments are >getting mixed up, I suspect because Robs patch creates a new apartment >but we still don't create a new listener thread for each apt (rather >it's still half process-scoped). > > Yes, Mike, you are correct. It is not half process-scoped, but instead now scoped with the wrong apartment. >We need to make the listener_thread properly apartment-scoped. > > Yes. Bill, you can either wait for my patch to fix local servers, or you can revert to ole32 as of 28th November. Rob

Dec. 18, 2004

Re: out-of-process COM design

by Bill Medland

On December 18, 2004 08:10 am, Mike Hearn wrote: > On Sat, 2004-12-18 at 07:46 -0800, Bill Medland wrote: > > 0013:trace:ole:listener_thread Process listener thread starting on > > (\\.\pipe\WINE_OLE_StubMgr_0000001000000011) > > ... > > > 0009:fixme:ole:PIPE_GetNewPipeBuf Could not open named pipe > > \\.\pipe\WINE_OLE_StubMgr_0000001000000014, le is 2 > > Well, now we have a variation on the same problem. The apartments are > getting mixed up, I suspect because Robs patch creates a new apartment > but we still don't create a new listener thread for each apt (rather > it's still half process-scoped). > > We need to make the listener_thread properly apartment-scoped. > > What does the trace+backtrace of the crash with my patch look like? 0009:trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:CoGetClassObject CLSID: {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, IID: {00000001-0000-0000-c000-000000000046} 0009:warn:ole:CoGetClassObject class {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} not registered inproc 0009:trace:ole:create_marshalled_proxy rclsid={b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, iid={00000001-0000-0000-c000-000000000046} 0009:trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:create_server activating local server 'L"G:\\runtime\\a4wsignonmgr.exe -Embedding"' for {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0014:trace:ole:DllMain 0x409e0000 0x1 0x1 0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 0014:trace:ole:DllMain (0x40ab0000,1,0x1) 0014:trace:ole:CoInitializeEx ((nil), 2) 0014:trace:ole:CoInitializeEx () - Initializing the COM libraries 0014:trace:ole:RunningObjectTableImpl_Initialize () 0014:trace:ole:WINE_StringFromCLSID 0x41f320->{A2086A6A-3F3E-457C-8102-A4F99AD7C2DA} 0014:trace:ole:CoRegisterClassObject ({b6b35894-dd6f-11d3-84ac-00c04f0e1b46},0x42130140,0x00000004,0x00000001,0x41f094) 0016:trace:ole:listener_thread Process listener thread starting on (\\.\pipe\WINE_OLE_StubMgr_0000001300000014) 0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 0017:trace:ole:_LocalServerThread Starting threader for {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}. 0017:trace:ole:WINE_StringFromCLSID 0x40246150->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0017:trace:ole:_LocalServerThread marshalling IClassFactory to client 0017:trace:ole:CoMarshalInterface (0x402372b8, {00000001-0000-0000-c000-000000000046}, 0x42130140, 0, (nil), 0) 0017:trace:ole:CoGetStandardMarshal ({00000001-0000-0000-c000-000000000046},0x42130140,0,(nil),0,0x42641fd0) 0017:trace:ole:CoMarshalInterface Using standard marshaling 0017:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace 0017:trace:ole:StdMarshalImpl_MarshalInterface (...,{00000001-0000-0000-c000-000000000046},...) 0017:trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x42641f64 0017:trace:ole:WINE_StringFromCLSID 0x40a22274->{00000001-0000-0000-C000-000000000046} 0017:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x42641f64 0017:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0017:trace:ole:WINE_StringFromCLSID 0x42641f64->{00000320-0000-0000-C000-000000000046} 0017:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0017:trace:ole:COMPOBJ_DLLList_Add 0017:trace:ole:PSFacBuf_CreateStub ({00000001-0000-0000-c000-000000000046},0x42130140,0x42641f50) 0009:trace:ole:CoUnmarshalInterface (0x40246d60, {00000001-0000-0000-c000-000000000046}, 0x406ef5dc) 0009:trace:ole:get_unmarshaler_from_stream Using standard unmarshaling 0009:trace:ole:StdMarshalImpl_UnmarshalInterface (...,{00000001-0000-0000-c000-000000000046},....) 0009:trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x406ef0d8 0009:trace:ole:WINE_StringFromCLSID 0x409a5274->{00000001-0000-0000-C000-000000000046} 0017:trace:ole:_LocalServerThread done marshalling IClassFactory 0009:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x406ef0d8 0009:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0009:trace:ole:WINE_StringFromCLSID 0x406ef0d8->{00000320-0000-0000-C000-000000000046} 0009:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0009:trace:ole:COMPOBJ_DLLList_Add 0009:trace:ole:CFProxy_CreateInstance ((nil),{00000000-0000-0000-c000-000000000046},0x406ef60c) 0009:trace:ole:PipeBuf_GetBuffer (0x406ef588,{00000001-0000-0000-c000-000000000046}) 0009:trace:ole:PipeBuf_SendReceive () 0018:trace:ole:_StubReaderThread STUB reader thread 13 0018:trace:ole:CFStub_Invoke ->CreateInstance({00000000-0000-0000-c000-000000000046}) 0018:trace:ole:CoMarshalInterface (0x40278858, {00000000-0000-0000-c000-000000000046}, 0x42130124, 0, (nil), 0) 0018:trace:ole:CoGetStandardMarshal ({00000000-0000-0000-c000-000000000046},0x42130124,0,(nil),0,0x42743024) 0018:trace:ole:CoMarshalInterface Using standard marshaling 0018:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace 0018:trace:ole:StdMarshalImpl_MarshalInterface (...,{00000000-0000-0000-c000-000000000046},...) wine: Unhandled exception (thread 0018), starting debugger... Backtrace: =>1 0x40901a13 StdMarshalImpl_MarshalInterface+0xa3(iface=0x40247148, pStm=0x40247100, riid=0x42a84138, pv=0x42480180, dwDestContext=0x0, pvDestContext=0x0, mshlflags=0x0) [/home/cvswine/wine/dlls/ole32/compobj_private.h:180] in ole32 (0x42a83ff4) 2 0x40902b07 CoMarshalInterface+0x227(pStream=0x40247100, riid=0x42a84138, pUnk=0x42480180, dwDestContext=0x0, pvDestContext=0x0, mshlFlags=0x0) [/home/cvswine/wine/dlls/ole32/marshal.c:719] in ole32 (0x42a840a4) 3 0x40908cff CFStub_Invoke+0x2e3(iface=0x40246fe8, msg=0x42a84170, chanbuf=0x0) [/home/cvswine/wine/dlls/ole32/oleproxy.c:178] in ole32 (0x42a84154) 4 0x4090acf2 COM_InvokeAndRpcSend+0x92(req=0x40247088) [/home/cvswine/wine/dlls/ole32/rpc.c:346] in ole32 (0x42a841ac) 5 0x4090bc9f _StubReaderThread+0xab(param=0x40246e90) [/home/cvswine/wine/dlls/ole32/rpc.c:745] in ole32 (0x42a841c4) 6 0x40396593 THREAD_Start+0xef(ptr=0x40246f70) [/home/cvswine/wine/dlls/kernel/thread.c:107] in kernel32 (0x42a84298) 7 0x400c314f start_thread+0x14b(info=0x40246f90) [/home/cvswine/wine/dlls/ntdll/thread.c:201] in ntdll (0x42a84ad4) 8 0x40044941 ?? +0x1b1 in libpthread.so.0 (0x42a84bd4) 9 0x420da1ca ?? +0x3a in libc.so.6 (0x00000000) Wine-dbg> -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 18, 2004

Re: Message Notify

by Duane Clark

M.hearn did not write: > <A virus> It appears to me that you have not used this email address (m.hearn.at.signal.QinetiQ.com) for a long time, at least not for sending to this list. If it is no longer in use, would you mind unsubscribing it to eliminate at least this one source of viruses?

Dec. 18, 2004

Re: out-of-process COM design

by Mike Hearn

On Sat, 2004-12-18 at 07:46 -0800, Bill Medland wrote: > 0013:trace:ole:listener_thread Process listener thread starting on (\\.\pipe\WINE_OLE_StubMgr_0000001000000011) ... > 0009:fixme:ole:PIPE_GetNewPipeBuf Could not open named pipe \\.\pipe\WINE_OLE_StubMgr_0000001000000014, le is 2 Well, now we have a variation on the same problem. The apartments are getting mixed up, I suspect because Robs patch creates a new apartment but we still don't create a new listener thread for each apt (rather it's still half process-scoped). We need to make the listener_thread properly apartment-scoped. What does the trace+backtrace of the crash with my patch look like?

Dec. 18, 2004

Re: out-of-process COM design

by Bill Medland

On December 18, 2004 05:03 am, Robert Shearman wrote: > Bill Medland wrote: > >On December 17, 2004 01:56 pm, Mike Hearn wrote: > >>On Fri, 17 Dec 2004 13:34:53 -0800, Bill Medland wrote: > >>>Well, it gets me past the illegal memory reference; I can start looking > >>>at what else failed now. > >> > >>In case you aren't already aware, Rob and I are doing a lot of work in > >>this area currently. If you want to pool resources that'd be good. > >> Posting a +ole trace of the failing app would be a good start. > >> > >>thanks -mike > > > >Pooling would be good. I'll help as much as I can. > > CUT > > Here's an untested patch. Let me know if it works. > > Rob If I combine it with Mike's patch I get the same null-Apt problem at a later point in the marshaling; I can give you a trace and bt if you want If I combine it with Rob's CoInitializeEx patch rather than Mike's then it executes but still fails, as follows: 0009:trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:CoGetClassObject CLSID: {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, IID: {00000001-0000-0000-c000-000000000046} 0009:warn:ole:CoGetClassObject class {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} not registered inproc 0009:trace:ole:create_marshalled_proxy rclsid={b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, iid={00000001-0000-0000-c000-000000000046} 0009:trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:create_server activating local server 'L"G:\\runtime\\a4wsignonmgr.exe -Embedding"' for {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0011:trace:ole:DllMain 0x409e0000 0x1 0x1 0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 0011:trace:ole:DllMain (0x40ab0000,1,0x1) 0011:trace:ole:CoInitializeEx ((nil), 2) 0011:trace:ole:CoInitializeEx () - Initializing the COM libraries 0011:trace:ole:RunningObjectTableImpl_Initialize () 0011:trace:ole:WINE_StringFromCLSID 0x41f320->{A2086A6A-3F3E-457C-8102-A4F99AD7C2DA} 0011:trace:ole:CoRegisterClassObject ({b6b35894-dd6f-11d3-84ac-00c04f0e1b46},0x42130180,0x00000004,0x00000001,0x41f094) 0013:trace:ole:listener_thread Process listener thread starting on (\\.\pipe\WINE_OLE_StubMgr_0000001000000011) 0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 0014:trace:ole:_LocalServerThread Starting threader for {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}. 0014:trace:ole:CoInitializeEx ((nil), 2) 0014:trace:ole:WINE_StringFromCLSID 0x40246118->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0014:trace:ole:_LocalServerThread marshalling IClassFactory to client 0014:trace:ole:CoMarshalInterface (0x40237280, {00000001-0000-0000-c000-000000000046}, 0x42130180, 0, (nil), 0) 0014:trace:ole:CoGetStandardMarshal ({00000001-0000-0000-c000-000000000046},0x42130180,0,(nil),0,0x42641fd0) 0014:trace:ole:CoMarshalInterface Using standard marshaling 0014:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace 0014:trace:ole:StdMarshalImpl_MarshalInterface (...,{00000001-0000-0000-c000-000000000046},...) 0014:trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x42641f64 0014:trace:ole:WINE_StringFromCLSID 0x40a221b4->{00000001-0000-0000-C000-000000000046} 0014:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x42641f64 0014:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0014:trace:ole:WINE_StringFromCLSID 0x42641f64->{00000320-0000-0000-C000-000000000046} 0014:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0014:trace:ole:COMPOBJ_DLLList_Add 0014:trace:ole:PSFacBuf_CreateStub ({00000001-0000-0000-c000-000000000046},0x42130180,0x42641f50) 0009:trace:ole:CoUnmarshalInterface (0x40246d28, {00000001-0000-0000-c000-000000000046}, 0x406ef5dc) 0009:trace:ole:get_unmarshaler_from_stream Using standard unmarshaling 0009:trace:ole:StdMarshalImpl_UnmarshalInterface (...,{00000001-0000-0000-c000-000000000046},....) 0009:trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x406ef0d8 0009:trace:ole:WINE_StringFromCLSID 0x409a51b4->{00000001-0000-0000-C000-000000000046} 0009:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x406ef0d8 0009:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0009:trace:ole:WINE_StringFromCLSID 0x406ef0d8->{00000320-0000-0000-C000-000000000046} 0009:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0009:trace:ole:COMPOBJ_DLLList_Add 0014:trace:ole:_LocalServerThread done marshalling IClassFactory 0009:fixme:ole:PIPE_GetNewPipeBuf Could not open named pipe \\.\pipe\WINE_OLE_StubMgr_0000001000000014, le is 2 0009:err:ole:StdMarshalImpl_UnmarshalInterface Failed to get an rpc channel buffer for {00000001-0000-0000-c000-000000000046} 0009:err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x80004005 0009:fixme:ole:CoCreateInstance no classfactory created for CLSID {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, hres is 0x80004005 -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 18, 2004

Re: out-of-process COM design

by Mike Hearn

On Sat, 2004-12-18 at 13:13 +0000, Robert Shearman wrote: > That patch is very hackish and needlessly complicated. This patch > accomplishes the same task in fewer lines (note that this is not the > best solution for the problem, I am working on that): > > Index: compobj.c > =================================================================== > RCS file: /home/wine/wine/dlls/ole32/compobj.c,v > retrieving revision 1.113 > diff -u -p -r1.113 compobj.c > --- compobj.c 14 Dec 2004 15:28:58 -0000 1.113 > +++ compobj.c 18 Dec 2004 13:58:03 -0000 > @@ -1107,6 +1107,8 @@ _LocalServerThread(LPVOID param) { > > TRACE("Starting threader for > %s.\n",debugstr_guid(&newClass->classIdentifier)); > > + CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); > + > strcpy(pipefn,PIPEPREF); > > WINE_StringFromCLSID(&newClass->classIdentifier,pipefn+strlen > (PIPEPREF)); That doesn't look right, it'll create a new apartment instead of using the one that the program itself created. I don't think we should be creating new apartments that don't correspond to anything the app did, Win32 generally expects the API user to do it manually. It'll make the code more confusing, especially once thread affinity is implemented.

Dec. 18, 2004

Re: out-of-process COM design

by Robert Shearman

Mike Hearn wrote: >On Fri, 17 Dec 2004 10:49:45 -0800, Bill Medland wrote: > > >>Does anyone know anything about this? e.g. when starting a new thread where >>does the apartment get initialized? >> >> > >It's supposed to get initialized in the call to CoInitialize[Ex] however >the _LocalServerThread never calls this as it's an internal implementation >detail of out of process DCOM. > >This looks like we haven't got the design quite right here, the >LocalServerThread doesn't exist in native DCOM as far as I can tell >so it may need to be replaced by something else. > > Rewriting this stuff is next on my todo list. The correct fix is to marshal it in the context of the calling thread, rather than in the new thread. This part is implemented in the native version as kind of a mix between the rpcrt4 thread pooling and undocumented local activator interfaces registered for each apartment. >The code in StdMarshalImpl is correct, the problem is that the local >server thread is violating the COM laws by using CoMarshalInterface before >entering an apartment. > >For now, does this patch help? > > > >Index: dlls/ole32/compobj.c >=================================================================== >RCS file: /home/wine/wine/dlls/ole32/compobj.c,v >retrieving revision 1.113 >diff -u -p -r1.113 compobj.c >--- dlls/ole32/compobj.c 14 Dec 2004 15:28:58 -0000 1.113 >+++ dlls/ole32/compobj.c 17 Dec 2004 19:13:22 -0000 >@@ -102,6 +102,7 @@ typedef struct tagRegisteredClass > DWORD connectFlags; > DWORD dwCookie; > HANDLE hThread; /* only for localserver */ >+ APARTMENT *apt; /* owning apartment */ > struct tagRegisteredClass* nextClass; > } RegisteredClass; > >@@ -1107,6 +1108,13 @@ _LocalServerThread(LPVOID param) { > > TRACE("Starting threader for %s.\n",debugstr_guid(&newClass->classIdentifier)); > >+ /* we need to enter the apartment of the thread which registered >+ * the class object to perform the next stage >+ */ >+ >+ assert( newClass->apt ); >+ NtCurrentTeb()->ReservedForOle = newClass->apt; >+ > strcpy(pipefn,PIPEPREF); > WINE_StringFromCLSID(&newClass->classIdentifier,pipefn+strlen(PIPEPREF)); > >@@ -1219,6 +1227,12 @@ HRESULT WINAPI CoRegisterClassObject( > if ( (lpdwRegister==0) || (pUnk==0) ) > return E_INVALIDARG; > >+ if (!COM_CurrentApt()) >+ { >+ ERR("COM was not initialized\n"); >+ return CO_E_NOTINITIALIZED; >+ } >+ > *lpdwRegister = 0; > > /* >@@ -1240,6 +1254,7 @@ HRESULT WINAPI CoRegisterClassObject( > newClass->classIdentifier = *rclsid; > newClass->runContext = dwClsContext; > newClass->connectFlags = flags; >+ newClass->apt = COM_CurrentApt(); > /* > * Use the address of the chain node as the cookie since we are sure it's > * unique. > > > That patch is very hackish and needlessly complicated. This patch accomplishes the same task in fewer lines (note that this is not the best solution for the problem, I am working on that): Index: compobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.113 diff -u -p -r1.113 compobj.c --- compobj.c 14 Dec 2004 15:28:58 -0000 1.113 +++ compobj.c 18 Dec 2004 13:58:03 -0000 @@ -1107,6 +1107,8 @@ _LocalServerThread(LPVOID param) { TRACE("Starting threader for %s.\n",debugstr_guid(&newClass->classIdentifier)); + CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); + strcpy(pipefn,PIPEPREF); WINE_StringFromCLSID(&newClass->classIdentifier,pipefn+strlen(PIPEPREF)); Rob

Dec. 18, 2004

Re: out-of-process COM design

by Robert Shearman

Bill Medland wrote: >On December 17, 2004 01:56 pm, Mike Hearn wrote: > > >>On Fri, 17 Dec 2004 13:34:53 -0800, Bill Medland wrote: >> >> >>>Well, it gets me past the illegal memory reference; I can start looking >>>at what else failed now. >>> >>> >>In case you aren't already aware, Rob and I are doing a lot of work in >>this area currently. If you want to pool resources that'd be good. Posting >>a +ole trace of the failing app would be a good start. >> >>thanks -mike >> >> >Pooling would be good. I'll help as much as I can. > >To start with, here's the relevant part of the trace. > >trace:ole:WINE_StringFromCLSID >0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} >trace:ole:CoGetClassObject > CLSID: {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, > IID: {00000001-0000-0000-c000-000000000046} >warn:ole:CoGetClassObject class {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} not >registered inproc >trace:ole:create_marshalled_proxy >rclsid={b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, >iid={00000001-0000-0000-c000-000000000046} >trace:ole:WINE_StringFromCLSID >0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} >trace:ole:WINE_StringFromCLSID >0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} >trace:ole:create_server activating local server >'L"G:\\runtime\\a4wsignonmgr.exe -Embedding"' for >{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} >trace:ole:DllMain 0x409e0000 0x1 0x1 >warn:ole:create_marshalled_proxy Could not open named pipe to broker >\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 >trace:ole:DllMain (0x40ab0000,1,0x1) >trace:ole:CoInitializeEx ((nil), 2) >trace:ole:CoInitializeEx () - Initializing the COM libraries >trace:ole:RunningObjectTableImpl_Initialize () >trace:ole:WINE_StringFromCLSID >0x41f320->{A2086A6A-3F3E-457C-8102-A4F99AD7C2DA} >trace:ole:CoRegisterClassObject >({b6b35894-dd6f-11d3-84ac-00c04f0e1b46},0x42130170,0x00000004,0x00000001,0x41f094) >trace:ole:listener_thread Process listener thread starting on >(\\.\pipe\WINE_OLE_StubMgr_00000010) > > Here's an untested patch. Let me know if it works. Rob

Dec. 18, 2004

Re: Version Detection

by Robert Shearman

Florian Goth wrote: >Well, I also have a problem with the Windows Version, while trying to install >a Windows Media Player. I have set the Windows Version in the config file to >Win95 . The First Problem is, that I can't Install WMP 6.4. It says that a >Version for Win2000 will be available sometime in the future. So I tried WMP >7.1. I get these Messages: >fixme:font:load_VDMX No suitable ratio found >fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please >report !! >fixme:propsheet:PROPSHEET_UnImplementedFlags PSH_RTLREADING >fixme:font:load_VDMX No suitable ratio found >fixme:font:load_VDMX No suitable ratio found >fixme:font:load_VDMX No suitable ratio found >fixme:ole:CoCreateInstance no classfactory created for CLSID >{cfc399af-d876-11d0-9c10-00c04fc99c8e}, hres is 0x80040154 > > 75% of the time, a CoCreateInstance fixme is the real cause of errors. In this case, it appears that it is trying to load some XML component (as shown by a quick Google search on the CLSID). I guess it needs MSXML installed before it will work. Rob

Dec. 18, 2004

Version Detection (this time for dcom98.exe)

by Paul Vriens

Hi, one of the first things I normally do after a fresh wine install is installing dcom98. This wasn't a problem before (use the correct overrides). Just tell me if I don't need this (anymore). Installing dcom98 with the current version checking is a different ballgame. Just running it with WINEDEBUG=+ver,+process shows the following versions: DCOM98.EXE trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") install.exe trace:ver:RtlGetVersion <-- Windows NT 4.0 (L"Service Pack 6a") rundll32.exe trace:ver:RtlGetVersion <-- Windows 95 (L"") in the trace. Simply overriding an application is not that easy anymore. dcom98 for examples launches 3 different executables. (I don't want to set the general OS override for now). Any ideas who to proceed with this (in general regarding versioning)? Cheers, Paul.

Dec. 18, 2004

Version Problems

by Florian Goth

BTW, I have a CVS-Wine from friday evening. First occurence: trace:ver:GetFileVersionInfoA ("c: \\windows\\system\\SHDOCVW.DLL",0,size=848,data=0x40432bd8) trace:ver:VERSION_GetFileVersionInfo_PE L"c:\\windows\\system\\SHDOCVW.DLL" trace:ver:print_vffi_debug structversion=1.0, fileversion=5.50.0.0, productversion=5.50.0.0, flagmask=0x0, flags= trace:ver:print_vffi_debug ( OS=0x0.0x0 UNKNOWN(0x0),BASE) trace:ver:print_vffi_debug filetype=DLL, trace:ver:print_vffi_debug filedata=0x0.0x0 But I have no such DLL there(It's set in the config file to builtin) Second: trace:ver:VERSION_GetLinkedDllVersion L"MSVCRT.dll": 06.00/04.00/00.00/04.00 trace:ver:VERSION_GetLinkedDllVersion 06.16/04.00/07.00/04.00 fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please report !! trace:ver:RtlGetVersion <-- Windows 98 (L" A ") hmmm. I remember having copied it from my win98 Installation(It is set in my config file to native,builtin . The complete trace: sifff(a)Skynet:~> wine mp71.exe trace:ver:VERSION_Init getting version from L"AppDefaults\\mp71.exe\\Version" trace:ver:VERSION_Init getting default version trace:ver:VERSION_GetLinkedDllVersion L"mp71.exe": 05.0c/05.00/05.00/04.00 trace:ver:VERSION_GetLinkedDllVersion 05.0c/05.00/05.00/04.00 trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:GetFileVersionInfoSizeW (L"c: \\windows\\system\\SHDOCVW.DLL",0x4096fba0) trace:ver:VERSION_GetFileVersionInfo_PE L"c:\\windows\\system\\SHDOCVW.DLL" trace:ver:print_vffi_debug structversion=1.0, fileversion=5.50.0.0, productversion=5.50.0.0, flagmask=0x0, flags= trace:ver:print_vffi_debug ( OS=0x0.0x0 UNKNOWN(0x0),BASE) trace:ver:print_vffi_debug filetype=DLL, trace:ver:print_vffi_debug filedata=0x0.0x0 trace:ver:GetFileVersionInfoA ("c: \\windows\\system\\SHDOCVW.DLL",0,size=848,data=0x40432bd8) trace:ver:VERSION_GetFileVersionInfo_PE L"c:\\windows\\system\\SHDOCVW.DLL" trace:ver:print_vffi_debug structversion=1.0, fileversion=5.50.0.0, productversion=5.50.0.0, flagmask=0x0, flags= trace:ver:print_vffi_debug ( OS=0x0.0x0 UNKNOWN(0x0),BASE) trace:ver:print_vffi_debug filetype=DLL, trace:ver:print_vffi_debug filedata=0x0.0x0 trace:ver:ConvertVersionInfo32To16 Converting 0x40432bd8 to 0x40432bd8 trace:ver:ConvertVersionInfo32To16 wLength 848, wValueLength 52, bText0, value 0x40432c00, child 0x40432c34 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432bde to 0x40432bdc: "VS_VERSION_INFO" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432c00 to 0x40432bec: 52 bytes trace:ver:ConvertVersionInfo32To16 Converting 0x40432c34 to 0x40432c20 trace:ver:ConvertVersionInfo32To16 wLength 688, wValueLength 0, bText 0, value 0x40432c58, child 0x40432c58 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432c3a to 0x40432c24: "StringFileInfo" trace:ver:ConvertVersionInfo32To16 No value present trace:ver:ConvertVersionInfo32To16 Converting 0x40432c58 to 0x40432c34 trace:ver:ConvertVersionInfo32To16 wLength 652, wValueLength 0, bText 0, value 0x40432c70, child 0x40432c70 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432c5e to 0x40432c38: "040904E4" trace:ver:ConvertVersionInfo32To16 No value present trace:ver:ConvertVersionInfo32To16 Converting 0x40432c70 to 0x40432c44 trace:ver:ConvertVersionInfo32To16 wLength 52, wValueLength 10, bText 1, value 0x40432c90, child 0x40432ca4 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432c76 to 0x40432c48: "CompanyName" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432c90 to 0x40432c54: "Wine Team" trace:ver:ConvertVersionInfo32To16 Finished, length is 28 (0x40432c44 - 0x40432c60) trace:ver:ConvertVersionInfo32To16 Converting 0x40432ca4 to 0x40432c60 trace:ver:ConvertVersionInfo32To16 wLength 68, wValueLength 14, bText 1, value 0x40432ccc, child 0x40432ce8 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432caa to 0x40432c64: "FileDescription" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432ccc to 0x40432c74: "Wine core dll" trace:ver:ConvertVersionInfo32To16 Finished, length is 36 (0x40432c60 - 0x40432c84) trace:ver:ConvertVersionInfo32To16 Converting 0x40432ce8 to 0x40432c84 trace:ver:ConvertVersionInfo32To16 wLength 50, wValueLength 9, bText 1, value 0x40432d08, child 0x40432d1c trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432cee to 0x40432c88: "FileVersion" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432d08 to 0x40432c94: "5.50.0.0" trace:ver:ConvertVersionInfo32To16 Finished, length is 28 (0x40432c84 - 0x40432ca0) trace:ver:ConvertVersionInfo32To16 Converting 0x40432d1c to 0x40432ca0 trace:ver:ConvertVersionInfo32To16 wLength 34, wValueLength 1, bText 1, value 0x40432d3c, child 0x40432d40 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432d22 to 0x40432ca4: "InternalName" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432d3c to 0x40432cb4: "" trace:ver:ConvertVersionInfo32To16 Finished, length is 24 (0x40432ca0 - 0x40432cb8) trace:ver:ConvertVersionInfo32To16 Converting 0x40432d40 to 0x40432cb8 trace:ver:ConvertVersionInfo32To16 wLength 220, wValueLength 92, bText1, value 0x40432d64, child 0x40432e1c trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432d46 to 0x40432cbc: "LegalCopyright" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432d64 to 0x40432ccc: "Copyright (c) 1993-2004 the Wine project authors (see the file AUTHORS for a complete list)" trace:ver:ConvertVersionInfo32To16 Finished, length is 112 (0x40432cb8- 0x40432d28) trace:ver:ConvertVersionInfo32To16 Converting 0x40432e1c to 0x40432d28 trace:ver:ConvertVersionInfo32To16 wLength 64, wValueLength 12, bText 1, value 0x40432e44, child 0x40432e5c trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432e22 to 0x40432d2c: "OriginalFilename" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432e44 to 0x40432d40: "shdocvw.dll" trace:ver:ConvertVersionInfo32To16 Finished, length is 36 (0x40432d28 - 0x40432d4c) trace:ver:ConvertVersionInfo32To16 Converting 0x40432e5c to 0x40432d4c trace:ver:ConvertVersionInfo32To16 wLength 42, wValueLength 5, bText 1, value 0x40432e7c, child 0x40432e88 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432e62 to 0x40432d50: "ProductName" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432e7c to 0x40432d5c: "Wine" trace:ver:ConvertVersionInfo32To16 Finished, length is 24 (0x40432d4c - 0x40432d64) trace:ver:ConvertVersionInfo32To16 Converting 0x40432e88 to 0x40432d64 trace:ver:ConvertVersionInfo32To16 wLength 46, wValueLength 5, bText 1, value 0x40432eac, child 0x40432eb8 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432e8e to 0x40432d68: "ProductVersion" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432eac to 0x40432d78: "5.50" trace:ver:ConvertVersionInfo32To16 Finished, length is 28 (0x40432d64 - 0x40432d80) trace:ver:ConvertVersionInfo32To16 Converting 0x40432eb8 to 0x40432d80 trace:ver:ConvertVersionInfo32To16 wLength 42, wValueLength 1, bText 1, value 0x40432ee0, child 0x40432ee4 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432ebe to 0x40432d84: "OLESelfRegister" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432ee0 to 0x40432d94: "" trace:ver:ConvertVersionInfo32To16 Finished, length is 24 (0x40432d80 - 0x40432d98) trace:ver:ConvertVersionInfo32To16 Finished, length is 356 (0x40432c34- 0x40432d98) trace:ver:ConvertVersionInfo32To16 Finished, length is 376 (0x40432c20- 0x40432d98) trace:ver:ConvertVersionInfo32To16 Converting 0x40432ee4 to 0x40432d98 trace:ver:ConvertVersionInfo32To16 wLength 68, wValueLength 0, bText 0, value 0x40432f04, child 0x40432f04 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432eea to 0x40432d9c: "VarFileInfo" trace:ver:ConvertVersionInfo32To16 No value present trace:ver:ConvertVersionInfo32To16 Converting 0x40432f04 to 0x40432da8 trace:ver:ConvertVersionInfo32To16 wLength 36, wValueLength 4, bText 0, value 0x40432f24, child 0x40432f28 trace:ver:ConvertVersionInfo32To16 Copied key from 0x40432f0a to 0x40432dac: "Translation" trace:ver:ConvertVersionInfo32To16 Copied value from 0x40432f24 to 0x40432db8: 4 bytes trace:ver:ConvertVersionInfo32To16 Finished, length is 20 (0x40432da8 - 0x40432dbc) trace:ver:ConvertVersionInfo32To16 Finished, length is 36 (0x40432d98 - 0x40432dbc) trace:ver:ConvertVersionInfo32To16 Finished, length is 484 (0x40432bd8- 0x40432dbc) trace:ver:VerQueryValueA (0x40432bd8,"\\",0x4096fbac,0x4096fb9c) trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") fixme:font:load_VDMX No suitable ratio found fixme:font:load_VDMX No suitable ratio found fixme:font:load_VDMX No suitable ratio found trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:VERSION_Init getting version from L"AppDefaults\\setup_wm.exe\\Version" trace:ver:VERSION_Init getting default version trace:ver:VERSION_GetLinkedDllVersion L"setup_wm.exe": 06.16/04.00/07.00/04.00 trace:ver:VERSION_GetLinkedDllVersion L"MSVCRT.dll": 06.00/04.00/00.00/04.00 trace:ver:VERSION_GetLinkedDllVersion 06.16/04.00/07.00/04.00 fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please report !! trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:GetFileVersionInfoSizeW (L"c: \\windows\\system\\msdxm.ocx",0x4097f408) trace:ver:VERSION_GetFileVersionInfo_PE L"c:\\windows\\system\\msdxm.ocx" trace:ver:print_vffi_debug structversion=1.0, fileversion=6.4.7.1112,productversion=6.4.7.1112, flagmask=0x30003f, flags= trace:ver:print_vffi_debug ( OS=0x0.0x4 UNKNOWN(0x0),WIN32) trace:ver:print_vffi_debug filetype=DLL, trace:ver:print_vffi_debug filedata=0x0.0x0 trace:ver:GetFileVersionInfoA ("c: \\windows\\system\\msdxm.ocx",0,size=900,data=0x41f316f0) trace:ver:VERSION_GetFileVersionInfo_PE L"c:\\windows\\system\\msdxm.ocx" trace:ver:print_vffi_debug structversion=1.0, fileversion=6.4.7.1112,productversion=6.4.7.1112, flagmask=0x30003f, flags= trace:ver:print_vffi_debug ( OS=0x0.0x4 UNKNOWN(0x0),WIN32) trace:ver:print_vffi_debug filetype=DLL, trace:ver:print_vffi_debug filedata=0x0.0x0 trace:ver:ConvertVersionInfo32To16 Converting 0x41f316f0 to 0x41f316f0 trace:ver:ConvertVersionInfo32To16 wLength 900, wValueLength 52, bText0, value 0x41f31718, child 0x41f3174c trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f316f6 to 0x41f316f4: "VS_VERSION_INFO" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f31718 to 0x41f31704: 52 bytes trace:ver:ConvertVersionInfo32To16 Converting 0x41f3174c to 0x41f31738 trace:ver:ConvertVersionInfo32To16 wLength 740, wValueLength 0, bText 1, value 0x41f31770, child 0x41f31770 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f31752 to 0x41f3173c: "StringFileInfo" trace:ver:ConvertVersionInfo32To16 No value present trace:ver:ConvertVersionInfo32To16 Converting 0x41f31770 to 0x41f3174c trace:ver:ConvertVersionInfo32To16 wLength 704, wValueLength 0, bText 1, value 0x41f31788, child 0x41f31788 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f31776 to 0x41f31750: "040904E4" trace:ver:ConvertVersionInfo32To16 No value present trace:ver:ConvertVersionInfo32To16 Converting 0x41f31788 to 0x41f3175c trace:ver:ConvertVersionInfo32To16 wLength 76, wValueLength 22, bText 1, value 0x41f317a8, child 0x41f317d4 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f3178e to 0x41f31760: "CompanyName" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f317a8 to 0x41f3176c: "Microsoft Corporation" trace:ver:ConvertVersionInfo32To16 Finished, length is 40 (0x41f3175c - 0x41f31784) trace:ver:ConvertVersionInfo32To16 Converting 0x41f317d4 to 0x41f31784 trace:ver:ConvertVersionInfo32To16 wLength 118, wValueLength 39, bText1, value 0x41f317fc, child 0x41f3184c trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f317da to 0x41f31788: "FileDescription" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f317fc to 0x41f31798: "Windows Media Player 2 ActiveX Control" trace:ver:ConvertVersionInfo32To16 Finished, length is 60 (0x41f31784 - 0x41f317c0) trace:ver:ConvertVersionInfo32To16 Converting 0x41f3184c to 0x41f317c0 trace:ver:ConvertVersionInfo32To16 wLength 56, wValueLength 12, bText 1, value 0x41f3186c, child 0x41f31884 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f31852 to 0x41f317c4: "FileVersion" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f3186c to 0x41f317d0: "6.4.07.1112" trace:ver:ConvertVersionInfo32To16 Finished, length is 28 (0x41f317c0 - 0x41f317dc) trace:ver:ConvertVersionInfo32To16 Converting 0x41f31884 to 0x41f317dc trace:ver:ConvertVersionInfo32To16 wLength 52, wValueLength 10, bText 1, value 0x41f318a4, child 0x41f318b8 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f3188a to 0x41f317e0: "InternalName" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f318a4 to 0x41f317f0: "MSDXM.OCX" trace:ver:ConvertVersionInfo32To16 Finished, length is 32 (0x41f317dc - 0x41f317fc) trace:ver:ConvertVersionInfo32To16 Converting 0x41f318b8 to 0x41f317fc trace:ver:ConvertVersionInfo32To16 wLength 116, wValueLength 40, bText1, value 0x41f318dc, child 0x41f3192c trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f318be to 0x41f31800: "LegalCopyright" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f318dc to 0x41f31810: "Copyright (C) 1992-1999 Microsoft Corp." trace:ver:ConvertVersionInfo32To16 Finished, length is 60 (0x41f317fc - 0x41f31838) trace:ver:ConvertVersionInfo32To16 Converting 0x41f3192c to 0x41f31838 trace:ver:ConvertVersionInfo32To16 wLength 60, wValueLength 10, bText 1, value 0x41f31954, child 0x41f31968 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f31932 to 0x41f3183c: "OriginalFilename" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f31954 to 0x41f31850: "MSDXM.OCX" trace:ver:ConvertVersionInfo32To16 Finished, length is 36 (0x41f31838 - 0x41f3185c) trace:ver:ConvertVersionInfo32To16 Converting 0x41f31968 to 0x41f3185c trace:ver:ConvertVersionInfo32To16 wLength 54, wValueLength 11, bText 1, value 0x41f31988, child 0x41f319a0 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f3196e to 0x41f31860: "ProductName" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f31988 to 0x41f3186c: "DirectShow" trace:ver:ConvertVersionInfo32To16 Finished, length is 28 (0x41f3185c - 0x41f31878) trace:ver:ConvertVersionInfo32To16 Converting 0x41f319a0 to 0x41f31878 trace:ver:ConvertVersionInfo32To16 wLength 60, wValueLength 12, bText 1, value 0x41f319c4, child 0x41f319dc trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f319a6 to 0x41f3187c: "ProductVersion" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f319c4 to 0x41f3188c: "6.4.07.1112" trace:ver:ConvertVersionInfo32To16 Finished, length is 32 (0x41f31878 - 0x41f31898) trace:ver:ConvertVersionInfo32To16 Converting 0x41f319dc to 0x41f31898 trace:ver:ConvertVersionInfo32To16 wLength 42, wValueLength 7, bText 1, value 0x41f319f8, child 0x41f31a08 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f319e2 to 0x41f3189c: "DirectShow" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f319f8 to 0x41f318a8: "Filter" trace:ver:ConvertVersionInfo32To16 Finished, length is 24 (0x41f31898 - 0x41f318b0) trace:ver:ConvertVersionInfo32To16 Converting 0x41f31a08 to 0x41f318b0 trace:ver:ConvertVersionInfo32To16 wLength 40, wValueLength 0, bText 1, value 0x41f31a30, child 0x41f31a30 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f31a0e to 0x41f318b4: "OLESelfRegister" trace:ver:ConvertVersionInfo32To16 No value present trace:ver:ConvertVersionInfo32To16 Finished, length is 20 (0x41f318b0 - 0x41f318c4) trace:ver:ConvertVersionInfo32To16 Finished, length is 376 (0x41f3174c- 0x41f318c4) trace:ver:ConvertVersionInfo32To16 Finished, length is 396 (0x41f31738- 0x41f318c4) trace:ver:ConvertVersionInfo32To16 Converting 0x41f31a30 to 0x41f318c4 trace:ver:ConvertVersionInfo32To16 wLength 68, wValueLength 0, bText 1, value 0x41f31a50, child 0x41f31a50 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f31a36 to 0x41f318c8: "VarFileInfo" trace:ver:ConvertVersionInfo32To16 No value present trace:ver:ConvertVersionInfo32To16 Converting 0x41f31a50 to 0x41f318d4 trace:ver:ConvertVersionInfo32To16 wLength 36, wValueLength 4, bText 0, value 0x41f31a70, child 0x41f31a74 trace:ver:ConvertVersionInfo32To16 Copied key from 0x41f31a56 to 0x41f318d8: "Translation" trace:ver:ConvertVersionInfo32To16 Copied value from 0x41f31a70 to 0x41f318e4: 4 bytes trace:ver:ConvertVersionInfo32To16 Finished, length is 20 (0x41f318d4 - 0x41f318e8) trace:ver:ConvertVersionInfo32To16 Finished, length is 36 (0x41f318c4 - 0x41f318e8) trace:ver:ConvertVersionInfo32To16 Finished, length is 504 (0x41f316f0- 0x41f318e8) trace:ver:VerQueryValueA (0x41f316f0,"\\",0x4097f430,0x4097f410) fixme:propsheet:PROPSHEET_UnImplementedFlags PSH_RTLREADING fixme:font:load_VDMX No suitable ratio found trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") fixme:font:load_VDMX No suitable ratio found trace:ver:RtlGetVersion <-- Windows 98 (L" A ") fixme:font:load_VDMX No suitable ratio found trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") fixme:ole:CoCreateInstance no classfactory created for CLSID {cfc399af-d876-11d0-9c10-00c04fc99c8e}, hres is 0x80040154 trace:ver:RtlGetVersion <-- Windows 98 (L" A ") trace:ver:RtlGetVersion <-- Windows 98 (L" A ") fixme:ole:CoCreateInstance no classfactory created for CLSID {cfc399af-d876-11d0-9c10-00c04fc99c8e}, hres is 0x80040154 trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4") trace:ver:RtlGetVersion <-- Windows 2000 (L"Service Pack 4")

Dec. 18, 2004

RE: Message Notify

by M.hearn

Dec. 18, 2004

Encrypted document

by Rklazes

Dec. 18, 2004

RE: Incoming Msg

by Rklazes

Dec. 18, 2004

Re: Document

by M.hearn

Dec. 18, 2004

Re: out-of-process COM design

by Mike Hearn

On Fri, 17 Dec 2004 14:27:30 -0800, Bill Medland wrote: > fixme:ole:PIPE_GetNewPipeBuf Could not open named pipe > \\.\pipe\WINE_OLE_StubMgr_0000001000000011, le is 2 I see the problem. The patch which switched us over to using OXIDs isn't complete, the listener_thread should be per-apartment not per-process, and the pipe it creates should therefore use the oxid >> 32 + oxid string formatter. Rob is travelling back to the UK today. I don't know when he'll be back online, or even if he'll be working over the Christmas period. If not I'll see if I can write a patch to fix this regression this weekend. thanks -mike

Dec. 18, 2004

Re: Version Detection

by Vincent Béron

Le ven 17/12/2004 à 17:25, Florian Goth a écrit : > Well, I also have a problem with the Windows Version, while trying to install > a Windows Media Player. I have set the Windows Version in the config file to > Win95 . The First Problem is, that I can't Install WMP 6.4. It says that a > Version for Win2000 will be available sometime in the future. So I tried WMP > 7.1. I get these Messages: > fixme:font:load_VDMX No suitable ratio found > fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please > report !! Try a WINEDEBUG=+ver run. That should give you the details of the version reported by the dll. You're looking for a line with "trace:ver:VERSION_GetLinkedDllVersion" and a bunch of numbers separated with slashes. Post it here, along with which dll it is exactly, if you can determine it. Vincent

Dec. 18, 2004

Re: out-of-process COM design

by Mike Hearn

On Fri, 17 Dec 2004 14:27:30 -0800, Bill Medland wrote: > Does anything jump out at you? > > (Ill get started on the learning curve) Well, the error messages describe what's going on. The question is, why? I clearly need to resurrect my out of process COM test program and make it a part of the test suite. BTW a +tid,+ole trace would be useful too, sorry I forgot about +tid before but it's really invaluable with DCOM stuff. thanks -mike

Dec. 17, 2004

Re: out-of-process COM design

by Bill Medland

On December 17, 2004 01:56 pm, Mike Hearn wrote: > On Fri, 17 Dec 2004 13:34:53 -0800, Bill Medland wrote: > > Well, it gets me past the illegal memory reference; I can start looking > > at what else failed now. > > In case you aren't already aware, Rob and I are doing a lot of work in > this area currently. If you want to pool resources that'd be good. Posting > a +ole trace of the failing app would be a good start. > > thanks -mike Pooling would be good. I'll help as much as I can. To start with, here's the relevant part of the trace. trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} trace:ole:CoGetClassObject CLSID: {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, IID: {00000001-0000-0000-c000-000000000046} warn:ole:CoGetClassObject class {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} not registered inproc trace:ole:create_marshalled_proxy rclsid={b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, iid={00000001-0000-0000-c000-000000000046} trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} trace:ole:WINE_StringFromCLSID 0x456ed8->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} trace:ole:create_server activating local server 'L"G:\\runtime\\a4wsignonmgr.exe -Embedding"' for {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} trace:ole:DllMain 0x409e0000 0x1 0x1 warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 trace:ole:DllMain (0x40ab0000,1,0x1) trace:ole:CoInitializeEx ((nil), 2) trace:ole:CoInitializeEx () - Initializing the COM libraries trace:ole:RunningObjectTableImpl_Initialize () trace:ole:WINE_StringFromCLSID 0x41f320->{A2086A6A-3F3E-457C-8102-A4F99AD7C2DA} trace:ole:CoRegisterClassObject ({b6b35894-dd6f-11d3-84ac-00c04f0e1b46},0x42130170,0x00000004,0x00000001,0x41f094) trace:ole:listener_thread Process listener thread starting on (\\.\pipe\WINE_OLE_StubMgr_00000010) warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 trace:ole:_LocalServerThread Starting threader for {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}. trace:ole:WINE_StringFromCLSID 0x40246118->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} trace:ole:_LocalServerThread marshalling IClassFactory to client trace:ole:CoMarshalInterface (0x40237280, {00000001-0000-0000-c000-000000000046}, 0x42130170, 0, (nil), 0) trace:ole:CoGetStandardMarshal ({00000001-0000-0000-c000-000000000046},0x42130170,0,(nil),0,0x42641fd0) trace:ole:CoMarshalInterface Using standard marshaling trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace trace:ole:StdMarshalImpl_MarshalInterface (...,{00000001-0000-0000-c000-000000000046},...) trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x42641f64 trace:ole:WINE_StringFromCLSID 0x40a23274->{00000001-0000-0000-C000-000000000046} trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x42641f64 trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} trace:ole:WINE_StringFromCLSID 0x42641f64->{00000320-0000-0000-C000-000000000046} trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} trace:ole:COMPOBJ_DLLList_Add trace:ole:PSFacBuf_CreateStub ({00000001-0000-0000-c000-000000000046},0x42130170,0x42641f50) trace:ole:CoUnmarshalInterface (0x4025a778, {00000001-0000-0000-c000-000000000046}, 0x406ef5dc) trace:ole:get_unmarshaler_from_stream Using standard unmarshaling trace:ole:StdMarshalImpl_UnmarshalInterface (...,{00000001-0000-0000-c000-000000000046},....) trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x406ef0d8 trace:ole:WINE_StringFromCLSID 0x409a5274->{00000001-0000-0000-C000-000000000046} trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x406ef0d8 trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} trace:ole:WINE_StringFromCLSID 0x406ef0d8->{00000320-0000-0000-C000-000000000046} trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} trace:ole:COMPOBJ_DLLList_Add trace:ole:_LocalServerThread done marshalling IClassFactory fixme:ole:PIPE_GetNewPipeBuf Could not open named pipe \\.\pipe\WINE_OLE_StubMgr_0000001000000011, le is 2 err:ole:StdMarshalImpl_UnmarshalInterface Failed to get an rpc channel buffer for {00000001-0000-0000-c000-000000000046} err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x80004005 fixme:ole:CoCreateInstance no classfactory created for CLSID {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, hres is 0x80004005 Does anything jump out at you? (Ill get started on the learning curve) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 17, 2004

Version Detection

by Florian Goth

Well, I also have a problem with the Windows Version, while trying to install a Windows Media Player. I have set the Windows Version in the config file to Win95 . The First Problem is, that I can't Install WMP 6.4. It says that a Version for Win2000 will be available sometime in the future. So I tried WMP 7.1. I get these Messages: fixme:font:load_VDMX No suitable ratio found fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please report !! fixme:propsheet:PROPSHEET_UnImplementedFlags PSH_RTLREADING fixme:font:load_VDMX No suitable ratio found fixme:font:load_VDMX No suitable ratio found fixme:font:load_VDMX No suitable ratio found fixme:ole:CoCreateInstance no classfactory created for CLSID {cfc399af-d876-11d0-9c10-00c04fc99c8e}, hres is 0x80040154 I can't install it also.It complains that it can't check the Internet for Updates.

Dec. 17, 2004

Re: out-of-process COM design

by Mike Hearn

On Fri, 17 Dec 2004 13:34:53 -0800, Bill Medland wrote: > Well, it gets me past the illegal memory reference; I can start looking at > what else failed now. In case you aren't already aware, Rob and I are doing a lot of work in this area currently. If you want to pool resources that'd be good. Posting a +ole trace of the failing app would be a good start. thanks -mike

Dec. 17, 2004