wine-devel

wine-devel@winehq.org

12 participants
84463 discussions

Trying to get rid of gdi.h
by Rémi Assailly 05 Jan '05

05 Jan '05

Hi all ! This mail is a resent because I noticed that it does not appear in wine-devel... I started a work to get rid of GDI_GetObjPtr and GDI_ReleaseObj in x11drv but I am not sure if have chosen a good way. This patch is incomplete : some GDI_* are still staying, those that cannot be removed using my way. Working on it I noticed something which can be interesting : graphics are faster because some times GDI_GetObjPtr were called twice and in my patch only once. I would some comments on this work. Rémi

1 0

Re: video4linux - wine
by Mike McCormack 05 Jan '05

05 Jan '05

MediaHost (TM) wrote: > However, is there any development going on concerning v4l and/or USB? > Actually it's a pity, that I couldn't realize this project....we would > have been willing to invest in such code.... I'm not sure what the capabilities of video4linux are, which devices it supports or how its API works. I know it supports at least some USB webcams. > As we can access /dev/usb/lpt or /dev/dsp, it should be possible to > access /dev/video....I'm not familiar in implementing such stuff at > wine, but....? The idea is to use the video4linux interface to implement the VFW API in Wine. The way I usually go about this kind of thing is to write a program or find a simple program (hopefully one with source code) that can grab a picture from a WebCam on Linux. Then run it in Wine, and see which error messages come out... then you'll have a starting point. Looks like there's souce for a simple program like that here: http://www.experts-exchange.com/Programming/Programming_Languages/Cplusplus… and documentation for VFW here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/h… Mike

1 0

Fwd: wineserver: fix get_update_region for desktop window
by Michael Jung 05 Jan '05

05 Jan '05

Alexandre, could you please give a short comment on this one? Thanks, Michael ---------- Forwarded Message ---------- Subject: wineserver: fix get_update_region for desktop window Date: Wednesday 05 January 2005 00:36 From: Michael Jung <mjung(a)iss.tu-darmstadt.de> To: wine-devel(a)winehq.org Cc: wine-patches(a)winehq.org Calling SetSysColor in the current cvs version of wine causes an infinite loop in update_now in dlls/user/painting.c. As I understand it, the problem is the following: get_update_flags will promote it's child window argument to the next child window (via a wineserver call to get_update_region), if the current child doesn't need any repaint. Calling get_update_flags on the desktop window will always return a repaint flag, so it never gets ahead. The attached patch automatically promotes the child window argument to the first child, if called on the desktop window. I don't know if this really is the desired behaviour. Another fix would be to not return any repaint flags for the desktop window. Ciao, Michael -------------------------------------------------------

2 1

Re: Fix for "Cluster size not supported" - resend
by Alexandre Julliard 05 Jan '05

05 Jan '05

Rein Klazes <wijn(a)wanadoo.nl> writes: > Totals size of the file system should be f_blocks * f_frsize, but that > gives a value 16 times too small. In this case f_blocks (as f_bfree, > f_bavail) are the number of f_bsize blocks, wrong. This is a quite > up-to-date system, Debian unstable with 2.6.10 kernel. > > Attached is the simplest solution, fall back to fstatfs() on Linux > systems. It is btw also what 'df' does. Wouldn't it be easier to simply use f_bsize instead of f_frsize? Why would switching to fstatfs be preferable? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [QUARTZ] Media Type Parsing
by Christian Costa 05 Jan '05

05 Jan '05

Paul Vriens wrote: >Hi, > >the Media Types use "Source Filter" instead of "File Source" in the registry. > >Changelog: >Media Types should use "Source Filter" instead of "File Source" > >Cheers, > >Paul Vriens. > >------------------------------------------------------------------------ > >--- regsvr.org.c 2005-01-05 11:37:05.894187368 +0100 >+++ regsvr.c 2005-01-05 12:39:03.985260298 +0100 >@@ -130,6 +130,8 @@ > 'S', 'u', 'b', 't', 'y', 'p', 'e', 0 }; > static WCHAR const filesource_valuename[12] = { > 'F', 'i', 'l', 'e', ' ', 'S', 'o', 'u', 'r', 'c', 'e', 0 }; >+static WCHAR const sourcefilter_valuename[14] = { >+ 'S', 'o', 'u', 'r', 'c', 'e', ' ', 'F', 'i', 'l', 't', 'e', 'r', 0 }; > static WCHAR const extensions_keyname[11] = { > 'E', 'x', 't', 'e', 'n', 's', 'i', 'o', 'n', 's', 0 }; > >@@ -391,7 +393,7 @@ > if (res != ERROR_SUCCESS) goto error_close_keys; > > StringFromGUID2(&CLSID_AsyncReader, buf, 39); >- res = RegSetValueExW(subtype_key, filesource_valuename, 0, REG_SZ, (CONST BYTE*)buf, >+ res = RegSetValueExW(subtype_key, sourcefilter_valuename, 0, REG_SZ, (CONST BYTE*)buf, > (lstrlenW(buf) + 1) * sizeof(WCHAR)); > if (res != ERROR_SUCCESS) goto error_close_keys; > > Good catch! It would be good to do the same for register_mediatypes_extension and then remove the filesource string. Bye, Christian

1 0

Re: video4linux - wine
by Jasper van Veghel 05 Jan '05

05 Jan '05

Rob Shearman wrote: > Mike McCormack wrote: > > > > >There's currently no support, but you could add it via the Still Image > >(STI) API. It's meant for scanners and webcams. There's probably a > >way to add VFW (Video For Windows drivers) too. > > > >I have written an IDL file for IStillImage, which I haven't gotten > >round to submitting as yet. I've attached it incase you're > >interested... I think it still needs some fixing up. > > > >Mike > > > > > >MediaHost (TM) wrote: > > > >>Question: Is there support for video4linux devices with wine? Is > >>there some support for webcams? What are the settings (config)? I > >>couldn't find anything useful on google concerning this issue.... > > > > You're probably much better off implementing a DirectShow -> V4L filter, > especially if you want to capture movies or sound. > > Rob > I've recently been looking into VFW with Wine, and though I certainly am no expert at the Windows API concerning this (first time I really looked into DX), nor Wine for that matter, I was able to get a bit further from where I started, so allow me to share my experiences with you. As an application to test this stuff with I went for MSN 6.2, though certainly not the best application for this, it seemed neat to finally have Webcam support on MSN - I eventually got some of it working with a load of native DLLs, some hacking on the SSL stuff (I ended up simply setting useSSL = false, the applica- tion was sending plain-text over an SSL socket, which wasn't working; this fixed things, or at least for this application ;-)) and adding some undocumented flag to InternetSetOption (optionId = 87) - anyway, it seems that MSN is using some- thing along the lines of the following webcam class I found using Google - indeed, using a DirectShow filter: http://www.jolash.com/projects/other_projects/webcam/WebCam.h For things to start working under Wine I used the following native DLLs, which I also registered with regsvr32 (for CLSIDs etc.) COMCTL32.DLL urlmon.dll CRYPT32.DLL MSOSS.DLL oleaut32.dll ole32.dll rpcrt4.dll MSVCRT.DLL shlwapi.dll shdocvw.dll MLANG.DLL qcap.dll amstream.dll Though I'm not sure if amstream is needed. Don't know what qcap does as I only managed to get to a point where something in qcap was called which was then being forwarded to Quartz (IAMStreamConfig, for which I added a bunch of stubs and semi-stubs (filled in some bogus information for VIDEO_STREAM_CONFIG_CAPS, VIDEOINFOHEADER and AM_MEDIA_TYPE) It turned out that, at least MSN, and this webcam class too, uses devenum to find the video input devices (CLSID_VideoInputDeviceCategory), for which I've added the proper code to CreateSpecialCategories and hence CreateClassEnumerator (it also seems that the windows DLL of devenum always recreates the dynamic registery entries whereas Wine only seems to add them once and then never again, that is, once they're in the registry they stay there (hence if a new audio card gets added to the system ..)) The Windows DLL seemed to be using avicap32 to collect information on the available video input devices, so I've simply had capGetDriverDescription return some string with a fictional video driver (this also makes it possible to use a native devenum.dll) Next up is Quartz, which seemed to want IAMStreamConfig (collecting information on the video stream (res, depth, sps, ..) for starters, but I never got around to implementing enough of that for the program to accept it and move on, so that's where I got stuck. It may also have had something to do with MSN wanting an IKsPin which isn't imple- mented (which is why native quartz may have failed, when trying to approach the kernel in some way) Here's a small scenario of what I observed working with both native and hacked up DLLs ;-) DEVENUM - Read all VideoInputDeviceRenderer's (from CLSID) DEVENUM - BindToObject() --> VfwCapture QCAP - BindToClass --> Quartz(VideoRenderer) QUARTZ - VideoRenderer_create QUARTZ - [FAIL] InputPin_QueryInterface (IKsPin) QUARTS - VideoRenderer_QueryInterface (IAMStreamConfig) Anyway, the 'patches' I wrote are probably not worth much as the whole under- taking was more of a little endeavor trying to see how far I go (MSN actually managed to sign in, by the way, but kept crashing a few seconds after that (the webcam stuff can be accessed without signing in though, there's a preview option in one of the menus), but perhaps this brief explanation of my steps will prove useful for someone wanting to implement this aspect of VFW :-) Perhaps someone could build a control from the class I mentioned earlier which can then be used for testing (through the webpage that refers to it says it's missing some code; but at least it's a starting point) Jasper

1 0

[QUARTZ] Fixes to regsvr.c (RESEND)
by Paul Vriens 05 Jan '05

05 Jan '05

Hi, the Media Types (and Media Type Extensions) use "Source Filter" instead of "File Source" in the registry. There were also some small typos. I will continue with changes to regsvr.c. My first goal is to have the native quartz running with the builtin registration ! Changelog: - Media Types (and Extensions) should use "Source Filter" instead of "File Source" - Removed filesource_valuename - Fixed typo for some class-names - Fixed typo in MPEG1System Media Type Cheers, Paul Vriens.

1 0

Trying to get rid of gdi.h
by Rémi Assailly 05 Jan '05

05 Jan '05

Hi all I started a work to get rid of GDI_GetObjPtr and GDI_ReleaseObj in x11drv but I am absolutely not sure if I have chosen a good way. What I send you is incomplete : some GDI_* are still staying and we cannot get rid of those functions using my way. After getting rid of GDI_* we'll be able to get rid of BITMAPOBJ* and PALETTEOBJ* using opaque pointers as Alexandre told me. Rémi

1 0

oleaut32 marshalling
by Bill Medland 05 Jan '05

05 Jan '05

Anyone any idea what is wrong here? In particular any idea why the xCall occurs almost immediately before the TMProxyImpl_Connect that would give it a channel to use? (The software works fine with a native oleaut32.dll) -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

2 2

question about the status of the wine printing system
by Udo Rader 05 Jan '05

05 Jan '05

Hi, I'm having some kind of hard time with wine's printing capabilities and have already started digging the wine sources for potential fixes to my problems (printing to some high volume postscript printers from some Adobe applications). But before I proceed any further, I would be grateful for some basic information on wine's printing system (unfortunately the documentation on this issue is somewhat "limited" :-) * Postscript level Googling the net some resources indicate that wine only supports postscript level 1 printing. Is this still true as of now? Does this also affect CUPS environments? * Postscript level vs. PPDs If wine only supports language level 1, why then does generic.ppd have its LanguageLevel set to 3? * starting point Most of the printing tasks are obviously handled by the stuff in dlls/wineps/*. Any other important nodes? happy hacking Udo Rader -- b e s t s o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ udo rader technischer leiter/CEM mobile ++43 660 5263642 ------------------------------------------------------------------------ eduard-bodem-gasse 8/3 A-6020 innsbruck fax ++43 512 935833 http://www.bestsolution.at phone ++43 512 935834

4 4

video4linux - wine
by MediaHost (TM) 05 Jan '05

05 Jan '05

Question: Is there support for video4linux devices with wine? Is there some support for webcams? What are the settings (config)? I couldn't find anything useful on google concerning this issue.... -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390

3 2

Re: [AppDB] Implement maintainer ratings.
by Paul van Schayck 05 Jan '05

05 Jan '05

Hey Tony, Few comments. > + maintainer_rating text, > + maintainer_release text, Why text, why not a varchar of 100 characters. It doesn't matter that much but it just optimizes our code a bit. > - $versionName = addslashes($_REQUEST['versionName']); > - $description = addslashes($_REQUEST['description']); > - $webPage = addslashes($_REQUEST['webPage']); > + $versionName = addslashes($_REQUEST['versionName']); > + $keywords = $_REQUEST['keywords']; > + $description = addslashes($_REQUEST['description']); > + $webPage = addslashes($_REQUEST['webPage']); > + $maintainer_rating = $_REQUEST['maintainer_rating']; > + $maintainer_release = $_REQUEST['maintainer_release']; > //did anything change? > if ($VersionChanged) > { > $query = "UPDATE appVersion SET versionName = '".$versionName."', ". > "keywords = '".$_REQUEST['keywords']."', ". > "description = '".$description."', ". > - "webPage = '".$webPage."'". > + "webPage = '".$webPage."',". > + "maintainer_rating = '".$maintainer_rating."',". > + "maintainer_release = '".$maintainer_release."'". > " WHERE appId = ".$_REQUEST['appId']." and versionId = ".$_REQUEST['versionId']; > if (mysql_query($query)) > { This is far from sql injection safe. Anyone can enter anything into $_REQUEST['mantainer_release'] or $_REQUEST['mantainer_rating'] and change any field from the appVersion table. It isn't a real problem in this case because they can already change most fields as maintainer. But they can for example change the versionId to make an app-version belong to any application. To prevent this we should make our queries with the compile_*_string functions from include/db.php. That function is doing addslashes. And generates an as safe as possible query string. Usage can be seen in admin/editAppFamily.php. Also query_appdb should be used instead of mysql_query(). And appId and versionId should always be check with is_numeric(). Right now without giving out details it's possible to change any application as long as you are maintainer of one application. Will you fix it or shall I? Paul

1 0

Wine Weekly News FROM THE FUTURE
by Scott Ritchie 05 Jan '05

05 Jan '05

Heh, just wanted to point out that the front page WWN article is for "January 31"

1 0

Crash in ACTION_InstallFiles when installing OpenOffice 1.9m65
by Dan Kegel 05 Jan '05

05 Jan '05

Every now and then, it's fun to try installing OpenOffice under Wine. Here's what happened when I tried it tonight with a copy of Wine built from yesterday's sources: $ wget http://openoffice.mirrors.pair.com/developer/680_m65/OOo_1.9.m65_native_Win… $ unzip OOo_1.9.m65_native_Win32Intel_install.zip $ rm -rf ~/.wine $ wine setup.exe ... wine: '/home/dank/.wine' created successfully. fixme:msi:MsiInstallProductW L"Z:\\home\\dank\\downloads\\OOo_1.9.m65_win\\openofficeorg1965.msi" L"" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"AppSearch" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"FindRelatedProducts" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"ValidateProductID" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"IsolateComponents" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"SetODBCFolders" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"MigrateFeatureStates" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveExistingProducts" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"AllocateRegistrySpace" fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:resolve_keypath UNIMPLEMENTED keypath as Registry or ODBC Source fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnpublishComponents" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"MsiUnpublishAssemblies" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnpublishFeatures" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterComPlus" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"SelfUnregModules" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterTypeLibraries" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveODBC" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterFonts" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveRegistryValues" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterClassInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterExtensionInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterProgIdInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterMIMEInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveIniValues" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveShortcuts" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveEnvironmentStrings" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveDuplicateFiles" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveFiles" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveFolders" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"MoveFiles" wine: Unhandled exception (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0 4077b200). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033 EIP:4077b200 ESP:4074f68c EBP:4074f690 EFLAGS:00010212( - 00 - RIA1) EAX:4074f6b0 EBX:4079f6d0 ECX:00000043 EDX:00000000 ESI:412563b8 EDI:77f01330 Stack dump: 0x4074f68c: 00000000 4074fae4 4077619a 00000000 0x4074f69c: 4074f6b0 4004c0e3 400d0624 00000000 0x4074f6ac: 4150a2f0 003a0043 0077005c 006e0069 0x4074f6bc: 006f0064 00730077 0074005c 006d0065 0x4074f6cc: 005c0070 006c0000 0061006f 00730064 0x4074f6dc: 004f005c 006f004f 0031005f 0039002e Backtrace: =>1 0x4077b200 strcpyW+0x17(dst=0x0, src=0x4074f6b0) [/home/dank/w/build2/dlls/msi/../../../wine/include/wine/unicode.h:190] in msi (0x4074f690) 2 0x4077619a ACTION_InstallFiles+0x262(package=0x412563b8) [../../../wine/dlls/msi/action.c:3162] in msi (0x4074fae4) 3 0x40770e8e ACTION_PerformAction+0x1e7(package=0x412563b8, action=0x4074fb18) [../../../wine/dlls/msi/action.c:1208] in msi (0x4074fb00) 4 0x40770971 ACTION_ProcessExecSequence+0x2c1(package=0x412563b8, UIran=0x0) [../../../wine/dlls/msi/action.c:1052] in msi (0x4074fd34) 5 0x4077040d ACTION_DoTopLevelINSTALL+0x33f(package=0x412563b8, szPackagePath=0x402470c0, szCommandLine=0x4023c2d8) [../../../wine/dlls/msi/action.c:856] in msi (0x4074fd90) 6 0x4077ed20 MsiInstallProductW+0xc9(szPackagePath=0x402470c0, szCommandLine=0x4023c2d8) [../../../wine/dlls/msi/msi.c:560] in msi (0x4074fdc0) 7 0x4077ec1e MsiInstallProductA+0x120(szPackagePath=0x401f04b9, szCommandLine=0x4023c2f8) [../../../wine/dlls/msi/msi.c:530] in msi (0x4074fde8) 8 0x40645985 main+0x1372(argc=0x3, argv=0x401f0488) [../../../wine/programs/msiexec/msiexec.c:616] in msiexec (0x4074fe8c) 9 0x40644163 __wine_exe_main+0x163 in msiexec (0x4074ff1c) 10 0x4037e1f3 start_process+0xdf(arg=0x0) [../../../wine/dlls/kernel/process.c:1046] in kernel32 (0x4074fff4) 11 0x400305e1 wine_pthread_abort_thread+0x2b(status=0x0) [../../../wine/libs/wine/port.c:86] in libwine.so.1 (0x00000000) -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

video4linux - wine
by StartCom Ltd. 05 Jan '05

05 Jan '05

1 0

wineserver: fix get_update_region for desktop window
by Michael Jung 04 Jan '05

04 Jan '05

Calling SetSysColor in the current cvs version of wine causes an infinite loop in update_now in dlls/user/painting.c. As I understand it, the problem is the following: get_update_flags will promote it's child window argument to the next child window (via a wineserver call to get_update_region), if the current child doesn't need any repaint. Calling get_update_flags on the desktop window will always return a repaint flag, so it never gets ahead. The attached patch automatically promotes the child window argument to the first child, if called on the desktop window. I don't know if this really is the desired behaviour. Another fix would be to not return any repaint flags for the desktop window. Ciao, Michael

1 0

Re: [OLE #21] Make apartment access thread safe, rework OLE TLS management
by Robert Shearman 04 Jan '05

04 Jan '05

Mike Hearn wrote: >On Mon, 2005-01-03 at 11:47 -0600, Robert Shearman wrote: > > >>>>Also, it may be best to split up the apartment structure into the stuff >>>>that really is apartment-local and the stuff that is thread-local, and >>>>then we have NtCurrentTeb()->ReservedForOle point to the thread-local >>>>structure, which has a member that points to the apartment struct. >>>> >>>> >>>That makes sense. I'll implement it now. >>> >>> >>One other thing: we also need the MTA to be dynamically allocated and >>destroyed and so therefore also ref counted. >> >>Rob >> >> > >OK, I implemented the new OLE TLS management, and it clears up the code >a lot, no more confusing apt->parent business. > >I didn't make the MTA dynamically allocated because this patch already >contains two changes that could really have been one given enough pain, >so I added it to the todo list instead. > >I think this patch is pretty much ready to go, the OLE TLS changes are >straightforward enough, so I'm CCing wine-patches. Any comments on the >last changes are welcome as usual. > >Alexandre: this patch is against the previous patches sent, so they must >be applied in order. > >Mike Hearn <mh(a)codeweavers.com> >- Make apartment access thread-safe by introducing refcounting and wider > usage of the apartment lock >- Rework OLE TLS management to eliminate uninitialised apartments and > parent chaining > > >------------------------------------------------------------------------ > >--- dlls/ole32/compobj.c (revision 67) >+++ dlls/ole32/compobj.c (local) >@@ -30,6 +30,8 @@ > * - Rewrite the CoLockObjectExternal code, it does totally the wrong > * thing currently (should be controlling the stub manager) > * >+ * - Make the MTA dynamically allocated and refcounted >+ * > * - Implement the service control manager (in rpcss) to keep track > * of registered class objects: ISCM::ServerRegisterClsid et al > * - Implement the OXID resolver so we don't need magic pipe names for >@@ -99,16 +101,17 @@ static void COM_ExternalLockFreeList(voi > > const CLSID CLSID_StdGlobalInterfaceTable = { 0x00000323, 0, 0, {0xc0, 0, 0, 0, 0, 0, 0, 0x46} }; > >-APARTMENT MTA, *apts; >+APARTMENT MTA; >+struct list apts = LIST_INIT( apts ); > >-static CRITICAL_SECTION csApartment; >+CRITICAL_SECTION csApartment; > static CRITICAL_SECTION_DEBUG critsect_debug = > { > 0, 0, &csApartment, > { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList }, > 0, 0, { 0, (DWORD)(__FILE__ ": csApartment") } > }; >-static CRITICAL_SECTION csApartment = { &critsect_debug, -1, 0, 0, 0, 0 }; >+CRITICAL_SECTION csApartment = { &critsect_debug, -1, 0, 0, 0, 0 }; > > I can't see the need to make this non-static at the moment. > > /* > * This lock count counts the number of times CoInitialize is called. It is >@@ -236,6 +239,7 @@ static void COM_UninitMTA(void) > MTA.oxid = 0; > } > >+ > /* creates an apartment structure which stores OLE thread-local > * information. Call with COINIT_UNINITIALIZED to create an apartment > * that will be initialized with a model later. Note: do not call >@@ -243,100 +247,138 @@ static void COM_UninitMTA(void) > * with a different COINIT value */ > APARTMENT* COM_CreateApartment(DWORD model) > { >- APARTMENT *apt; >- BOOL create = (NtCurrentTeb()->ReservedForOle == NULL); >+ APARTMENT *apt = COM_CurrentApt(); > >- if (create) >+ if (!apt) > { >+ if (model & COINIT_MULTITHREADED) >+ { >+ TRACE("thread 0x%lx is entering the multithreaded apartment\n", GetCurrentThreadId()); >+ COM_CurrentInfo()->apt = &MTA; >+ return apt; >+ } >+ >+ TRACE("creating new apartment, model=%ld\n", model); >+ > apt = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(APARTMENT)); > apt->tid = GetCurrentThreadId(); > DuplicateHandle(GetCurrentProcess(), GetCurrentThread(), > GetCurrentProcess(), &apt->thread, > THREAD_ALL_ACCESS, FALSE, 0); >- } >- else >- apt = NtCurrentTeb()->ReservedForOle; > >- list_init(&apt->proxies); >- list_init(&apt->stubmgrs); >- apt->oidc = 1; >- >- apt->model = model; >- if (model & COINIT_APARTMENTTHREADED) { >- /* FIXME: how does windoze create OXIDs? */ >- apt->oxid = MTA.oxid | GetCurrentThreadId(); >- apt->win = CreateWindowA(aptWinClass, NULL, 0, >- 0, 0, 0, 0, >- 0, 0, OLE32_hInstance, NULL); >- InitializeCriticalSection(&apt->cs); >- } >- else if (!(model & COINIT_UNINITIALIZED)) { >- apt->parent = &MTA; >- apt->oxid = MTA.oxid; >- } >- EnterCriticalSection(&csApartment); >- if (create) >- { >- if (apts) apts->prev = apt; >- apt->next = apts; >- apts = apt; >+ list_init(&apt->stubmgrs); >+ apt->oidc = 1; >+ InitializeCriticalSection(&apt->cs); >+ >+ apt->model = model; >+ >+ /* we don't ref the apartment as CoInitializeEx will do it for us */ >+ >+ if (model & COINIT_APARTMENTTHREADED) >+ { >+ /* FIXME: how does windoze create OXIDs? */ >+ apt->oxid = MTA.oxid | GetCurrentThreadId(); >+ apt->win = CreateWindowA(aptWinClass, NULL, 0, >+ 0, 0, 0, 0, >+ 0, 0, OLE32_hInstance, NULL); >+ } >+ >+ EnterCriticalSection(&csApartment); >+ list_add_head(&apts, &apt->entry); >+ LeaveCriticalSection(&csApartment); >+ >+ COM_CurrentInfo()->apt = apt; > } >- LeaveCriticalSection(&csApartment); >- NtCurrentTeb()->ReservedForOle = apt; >+ > return apt; > } > >-static void COM_DestroyApartment(APARTMENT *apt) >+DWORD COM_ApartmentAddRef(APARTMENT *apt) >+{ >+ return InterlockedIncrement(&apt->refs); >+} >+ >+/* if null, use current apt and on destroy clear the TEB apt field */ >+DWORD COM_ApartmentRelease(APARTMENT *apartment) > > I don't really like functions like this doing special things on certain input values. I don't think it is that big a deal to require the few callers of this function to go to the effort of getting the apartment themselves. > { >+ APARTMENT *apt = apartment ? apartment : COM_CurrentInfo()->apt; >+ > EnterCriticalSection(&csApartment); >- if (apt->prev) apt->prev->next = apt->next; >- if (apt->next) apt->next->prev = apt->prev; >- if (apts == apt) apts = apt->next; >- apt->prev = NULL; apt->next = NULL; >- LeaveCriticalSection(&csApartment); >- if (apt->model & COINIT_APARTMENTTHREADED) { >- /* disconnect proxies to release the corresponding stubs. >- * It is confirmed in "Essential COM" in the sub-chapter on >- * "Lifecycle Management and Marshalling" that the native version also >- * disconnects proxies in this function. */ >- /* FIXME: this should also be called for MTA destruction, but that >- * requires restructuring how apartments work slightly. */ >- MARSHAL_Disconnect_Proxies(apt); > >- if (apt->win) DestroyWindow(apt->win); >- DeleteCriticalSection(&apt->cs); >+ if (InterlockedDecrement(&apt->refs) == 0) >+ { >+ TRACE("destroying apartment %p, oxid %s\n", apt, wine_dbgstr_longlong(apt->oxid)); >+ >+ if (!apartment) COM_CurrentInfo()->apt = NULL; >+ >+ MARSHAL_Disconnect_Proxies(apt); >+ >+ list_remove(&apt->entry); >+ if ((apt->model & COINIT_APARTMENTTHREADED) && apt->win) DestroyWindow(apt->win); >+ >+ if (!list_empty(&apt->stubmgrs)) >+ { >+ FIXME("PANIC: Apartment being destroyed with outstanding stubs, what do we do now?\n"); > > To answer your question: forcefully destroy them all. >+ } >+ >+ if (apt->filter) IUnknown_Release(apt->filter); >+ >+ >+ DeleteCriticalSection(&apt->cs); >+ CloseHandle(apt->thread); >+ HeapFree(GetProcessHeap(), 0, apt); >+ >+ apt = NULL; > } >- CloseHandle(apt->thread); >- HeapFree(GetProcessHeap(), 0, apt); >-} > >-/* The given OXID must be local to this process: you cannot use apartment >- windows to send RPCs to other processes. This all needs to move to rpcrt4 */ >+ LeaveCriticalSection(&csApartment); > >-APARTMENT *COM_ApartmentFromOXID(OXID oxid) >+ return apt ? apt->refs : 0; >+} >+ >+/* The given OXID must be local to this process: you cannot use >+ * apartment windows to send RPCs to other processes. This all needs >+ * to move to rpcrt4. >+ * >+ * The ref parameter is here mostly to ensure people remember that >+ * they get one, you should normally take a ref for thread safety. >+ */ >+APARTMENT *COM_ApartmentFromOXID(OXID oxid, BOOL ref) > { >- APARTMENT *apt = NULL; >+ APARTMENT *result = NULL; >+ struct list *cursor; > > EnterCriticalSection(&csApartment); >- apt = apts; >- while (apt && apt->oxid != oxid) apt = apt->next; >+ LIST_FOR_EACH( cursor, &apts ) >+ { >+ struct apartment *apt = LIST_ENTRY( cursor, struct apartment, entry ); >+ if (apt->oxid == oxid) >+ { >+ result = apt; >+ if (ref) COM_ApartmentAddRef(result); >+ break; >+ } >+ } > LeaveCriticalSection(&csApartment); > >- return apt; >+ return result; > } > >-HWND COM_GetApartmentWin(OXID oxid) >+HWND COM_GetApartmentWin(OXID oxid, BOOL ref) > { >- APARTMENT *apt = COM_ApartmentFromOXID(oxid); >+ APARTMENT *apt; > >- return apt ? apt->win : NULL; >+ apt = COM_ApartmentFromOXID(oxid, ref); >+ if (!apt) return NULL; >+ >+ return apt->win; > } > > /* Currently inter-thread marshalling is not fully implemented, so this does nothing */ > static LRESULT CALLBACK COM_AptWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) > { > return DefWindowProcA(hWnd, msg, wParam, lParam); >-} >+} > > /***************************************************************************** > * This section contains OpenDllList implemantation >@@ -467,8 +509,7 @@ HRESULT WINAPI CoInitialize( > * CoUninitialize > */ > HRESULT WINAPI CoInitializeEx( >- LPVOID lpReserved, /* [in] pointer to win32 malloc interface >- (obsolete, should be NULL) */ >+ LPVOID lpReserved, /* [in] pointer to win32 malloc interface (obsolete, should be NULL) */ > DWORD dwCoInit /* [in] A value from COINIT specifies the threading model */ > ) > { >@@ -482,21 +523,6 @@ HRESULT WINAPI CoInitializeEx( > ERR("(%p, %x) - Bad parameter passed-in %p, must be an old Windows Application\n", lpReserved, (int)dwCoInit, lpReserved); > } > >- apt = NtCurrentTeb()->ReservedForOle; >- if (apt && !(apt->model == COINIT_UNINITIALIZED)) >- { >- if (dwCoInit != apt->model) >- { >- /* Changing the threading model after it's been set is illegal. If this warning is triggered by Wine >- code then we are probably using the wrong threading model to implement that API. */ >- ERR("Attempt to change threading model of this apartment from 0x%lx to 0x%lx\n", apt->model, dwCoInit); >- return RPC_E_CHANGED_MODE; >- } >- hr = S_FALSE; >- } >- else >- hr = S_OK; >- > /* > * Check the lock count. If this is the first time going through the initialize > * process, we have to initialize the libraries. >@@ -512,13 +538,22 @@ HRESULT WINAPI CoInitializeEx( > > COM_InitMTA(); > >+ /* we may need to defer this until after apartment initialisation */ > RunningObjectTableImpl_Initialize(); > } > >- if (!apt || apt->model == COINIT_UNINITIALIZED) apt = COM_CreateApartment(dwCoInit); >+ /* doing this twice is harmless */ >+ apt = COM_CreateApartment(dwCoInit); > >- InterlockedIncrement(&apt->inits); >- if (hr == S_OK) NtCurrentTeb()->ReservedForOle = apt; >+ if (dwCoInit != apt->model) >+ { >+ /* Changing the threading model after it's been set is illegal. If this warning is triggered by Wine >+ code then we are probably using the wrong threading model to implement that API. */ >+ ERR("Attempt to change threading model of this apartment from 0x%lx to 0x%lx\n", apt->model, dwCoInit); >+ return RPC_E_CHANGED_MODE; >+ } >+ >+ InterlockedIncrement(&apt->refs); > > I think it would be cleaner to put the ref-count increment inside the apartment creation function. That way, no callers of the COM_CreateApartment function can make the mistake of creating an apartment without incrementing its refcount. > > return hr; > } >@@ -529,14 +564,20 @@ HRESULT WINAPI CoInitializeEx( > void COM_FlushMessageQueue(void) > { > MSG message; >- APARTMENT *apt = NtCurrentTeb()->ReservedForOle; >+ APARTMENT *apt = COM_CurrentApt(); > > if (!apt || !apt->win) return; > > TRACE("Flushing STA message queue\n"); > >- while (PeekMessageA(&message, NULL, 0, 0, PM_REMOVE)) { >- if (message.hwnd != apt->win) continue; >+ while (PeekMessageA(&message, NULL, 0, 0, PM_REMOVE)) >+ { >+ if (message.hwnd != apt->win) >+ { >+ WARN("discarding message 0x%x for window %p\n", message.message, message.hwnd); >+ continue; >+ } >+ > TranslateMessage(&message); > DispatchMessageA(&message); > } >@@ -561,17 +602,10 @@ void COM_FlushMessageQueue(void) > void WINAPI CoUninitialize(void) > { > LONG lCOMRefCnt; >- APARTMENT *apt; > > TRACE("()\n"); > >- apt = NtCurrentTeb()->ReservedForOle; >- if (!apt) return; >- if (InterlockedDecrement(&apt->inits)==0) { >- NtCurrentTeb()->ReservedForOle = NULL; >- COM_DestroyApartment(apt); >- apt = NULL; >- } >+ COM_ApartmentRelease(NULL); > > /* > * Decrease the reference count. >@@ -1134,14 +1168,14 @@ end: > > /****************************************************************************** > * CoRegisterClassObject [OLE32.@] >- * >+ * > * Registers the class object for a given class ID. Servers housed in EXE > * files use this method instead of exporting DllGetClassObject to allow > * other code to connect to their objects. > * > * RETURNS >- * S_OK on success, >- * E_INVALIDARG if lpdwRegister or pUnk are NULL, >+ * S_OK on success, >+ * E_INVALIDARG if lpdwRegister or pUnk are NULL, > * CO_E_OBJISREG if the object is already registered. We should not return this. > * > * SEE ALSO >@@ -1217,7 +1251,7 @@ HRESULT WINAPI CoRegisterClassObject( > if (dwClsContext & CLSCTX_LOCAL_SERVER) { > IClassFactory *classfac; > >- hr = IUnknown_QueryInterface(newClass->classObject, &IID_IClassFactory, >+ hr = IUnknown_QueryInterface(newClass->classObject, &IID_IClassFactory, > (LPVOID*)&classfac); > if (hr) return hr; > >@@ -1556,7 +1590,7 @@ HRESULT WINAPI CoCreateInstance( > LPCLASSFACTORY lpclf = 0; > > if (!COM_CurrentApt()) return CO_E_NOTINITIALIZED; >- >+ > /* > * Sanity check > */ >@@ -1573,15 +1607,15 @@ HRESULT WINAPI CoCreateInstance( > * Rather than create a class factory, we can just check for it here > */ > if (IsEqualIID(rclsid, &CLSID_StdGlobalInterfaceTable)) { >- if (StdGlobalInterfaceTableInstance == NULL) >+ if (StdGlobalInterfaceTableInstance == NULL) > StdGlobalInterfaceTableInstance = StdGlobalInterfaceTable_Construct(); > hres = IGlobalInterfaceTable_QueryInterface( (IGlobalInterfaceTable*) StdGlobalInterfaceTableInstance, iid, ppv); > if (hres) return hres; >- >+ > TRACE("Retrieved GIT (%p)\n", *ppv); > return S_OK; > } >- >+ > /* > * Get a class factory to construct the object we want. > */ >@@ -2000,19 +2034,21 @@ HRESULT WINAPI CoInitializeWOW(DWORD x,D > */ > HRESULT WINAPI CoGetState(IUnknown ** ppv) > { >- APARTMENT * apt = COM_CurrentInfo(); >+ HRESULT hr = E_FAIL; > >- FIXME("\n"); >+ FIXME("possible stub\n"); > > > I believe the function does everything that is required of it - the only problem is that we don't currently do anything with the state. I'm not sure if we should though. >- if(apt && apt->state) { >- IUnknown_AddRef(apt->state); >- *ppv = apt->state; >- FIXME("-- %p\n", *ppv); >- return S_OK; >- } >- *ppv = NULL; >- return E_FAIL; >+ *ppv = NULL; >+ >+ if (COM_CurrentInfo()->state) >+ { >+ IUnknown_AddRef(COM_CurrentInfo()->state); >+ *ppv = COM_CurrentInfo()->state; >+ TRACE("apt->state=%p\n", COM_CurrentInfo()->state); >+ hr = S_OK; >+ } > >+ return hr; > } > > /*********************************************************************** >@@ -2021,22 +2057,19 @@ HRESULT WINAPI CoGetState(IUnknown ** pp > */ > HRESULT WINAPI CoSetState(IUnknown * pv) > { >- APARTMENT * apt = COM_CurrentInfo(); >+ FIXME("(%p),stub!\n", pv); > >- if (!apt) apt = COM_CreateApartment(COINIT_UNINITIALIZED); >+ if (pv) IUnknown_AddRef(pv); > >- FIXME("(%p),stub!\n", pv); >+ if (COM_CurrentInfo()->state) >+ { >+ TRACE("-- release %p now\n", COM_CurrentInfo()->state); >+ IUnknown_Release(COM_CurrentInfo()->state); >+ } > >- if (pv) { >- IUnknown_AddRef(pv); >- } >+ COM_CurrentInfo()->state = pv; > >- if (apt->state) { >- TRACE("-- release %p now\n", apt->state); >- IUnknown_Release(apt->state); >- } >- apt->state = pv; >- return S_OK; >+ return S_OK; > } > > >@@ -2191,7 +2224,7 @@ HRESULT WINAPI CoGetTreatAsClass(REFCLSI > done: > if (hkey) RegCloseKey(hkey); > return res; >- >+ > } > > /*********************************************************************** >--- dlls/ole32/compobj_private.h (revision 67) >+++ dlls/ole32/compobj_private.h (local) >@@ -38,12 +38,8 @@ > #include "winreg.h" > #include "winternl.h" > >-/* Windows maps COINIT values to 0x80 for apartment threaded, 0x140 >- * for free threaded, and 0 for uninitialized apartments. There is >- * no real advantage in us doing this and certainly no release version >- * of an app should be poking around with these flags. So we need a >- * special value for uninitialized */ >-#define COINIT_UNINITIALIZED 0x100 >+struct apartment; >+ > > /* exported interface */ > typedef struct tagXIF { >@@ -59,7 +55,7 @@ typedef struct tagXIF { > /* exported object */ > typedef struct tagXOBJECT { > IRpcStubBufferVtbl *lpVtbl; >- struct tagAPARTMENT *parent; >+ struct apartment *parent; > struct tagXOBJECT *next; > LPUNKNOWN obj; /* object identity (IUnknown) */ > OID oid; /* object ID */ >@@ -83,7 +79,7 @@ struct ifproxy > struct proxy_manager > { > const IInternalUnknownVtbl *lpVtbl; >- struct tagAPARTMENT *parent; >+ struct apartment *parent; > struct list entry; > LPRPCCHANNELBUFFER chan; /* channel to object */ > OXID oxid; /* object exported ID */ >@@ -93,11 +89,13 @@ struct proxy_manager > CRITICAL_SECTION cs; /* thread safety for this object and children */ > }; > >-/* apartment */ >-typedef struct tagAPARTMENT { >- struct tagAPARTMENT *next, *prev, *parent; >+/* this needs to become a COM object that implements IRemUnknown */ >+struct apartment >+{ >+ struct list entry; >+ >+ DWORD refs; /* refcount of the apartment */ > DWORD model; /* threading model */ >- DWORD inits; /* CoInitialize count */ > > This should be moved into the TLS struct, not removed entirely. > DWORD tid; /* thread id */ > HANDLE thread; /* thread handle */ > OXID oxid; /* object exporter ID */ >@@ -107,13 +105,12 @@ typedef struct tagAPARTMENT { > LPMESSAGEFILTER filter; /* message filter */ > XOBJECT *objs; /* exported objects */ > struct list proxies; /* imported objects */ >- LPUNKNOWN state; /* state object (see Co[Get,Set]State) */ > LPVOID ErrorInfo; /* thread error info */ > > You can remove this - it should no longer be needed. > DWORD listenertid; /* id of apartment_listener_thread */ > struct list stubmgrs; /* stub managers for exported objects */ >-} APARTMENT; >+}; > >-extern APARTMENT MTA, *apts; >+typedef struct apartment APARTMENT; > > extern void* StdGlobalInterfaceTable_Construct(void); > extern void StdGlobalInterfaceTable_Destroy(void* self); >@@ -196,27 +193,41 @@ int WINAPI FileMonikerImpl_DecomposePath > > HRESULT WINAPI __CLSIDFromStringA(LPCSTR idstr, CLSID *id); > >+/* compobj.c */ >+APARTMENT *COM_CreateApartment(DWORD model); >+APARTMENT *COM_ApartmentFromOXID(OXID oxid, BOOL ref); >+DWORD COM_ApartmentAddRef(APARTMENT *apt); >+DWORD COM_ApartmentRelease(APARTMENT *apt); >+ >+extern CRITICAL_SECTION csApartment; >+ >+/* this is what is stored in TEB->ReservedForOle */ >+struct oletls >+{ >+ struct apartment *apt; >+ IErrorInfo *errorinfo; /* see errorinfo.c */ >+ IUnknown *state; /* see CoSetState */ >+}; >+ > /* > * Per-thread values are stored in the TEB on offset 0xF80, > * see http://www.microsoft.com/msj/1099/bugslayer/bugslayer1099.htm > */ >-static inline APARTMENT* COM_CurrentInfo(void) >+ >+/* will create if necessary */ >+static inline struct oletls *COM_CurrentInfo(void) > { >- APARTMENT* apt = NtCurrentTeb()->ReservedForOle; >- return apt; >+ if (!NtCurrentTeb()->ReservedForOle) >+ NtCurrentTeb()->ReservedForOle = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct oletls)); > > I guess are ignoring failures from HeapAlloc then. There isn't really much we can do about it anyway though. >+ >+ return NtCurrentTeb()->ReservedForOle; > } >+ > static inline APARTMENT* COM_CurrentApt(void) >-{ >- APARTMENT* apt = COM_CurrentInfo(); >- if (apt && apt->parent) apt = apt->parent; >- return apt; >+{ >+ return COM_CurrentInfo()->apt; > } > >-/* compobj.c */ >-APARTMENT *COM_CreateApartment(DWORD model); >-HWND COM_GetApartmentWin(OXID oxid); >-APARTMENT *COM_ApartmentFromOXID(OXID oxid); >- > #define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) > > #endif /* __WINE_OLE_COMPOBJ_H */ >--- dlls/ole32/errorinfo.c (revision 67) >+++ dlls/ole32/errorinfo.c (local) >@@ -20,7 +20,8 @@ > * NOTES: > * > * The errorinfo is a per-thread object. The reference is stored in the >- * TEB at offset 0xf80 >+ * TEB at offset 0xf80. Does anything actually access this directly? >+ * If not we should make this use a different field and drop the apt->parent hack. > */ > > > Nothing should reference it directly as the offset is OS dependent. > #include <stdarg.h> >@@ -483,20 +484,20 @@ HRESULT WINAPI CreateErrorInfo(ICreateEr > */ > HRESULT WINAPI GetErrorInfo(ULONG dwReserved, IErrorInfo **pperrinfo) > { >- APARTMENT * apt = COM_CurrentInfo(); >- >- TRACE("(%ld, %p, %p)\n", dwReserved, pperrinfo, COM_CurrentInfo()->ErrorInfo); >+ TRACE("(%ld, %p, %p)\n", dwReserved, pperrinfo, COM_CurrentInfo()->errorinfo); > > if(!pperrinfo) return E_INVALIDARG; >- if (!apt || !apt->ErrorInfo) >+ >+ if (!COM_CurrentInfo()->errorinfo) > { > *pperrinfo = NULL; > return S_FALSE; > } > >- *pperrinfo = (IErrorInfo*)(apt->ErrorInfo); >+ *pperrinfo = COM_CurrentInfo()->errorinfo; >+ > /* clear thread error state */ >- apt->ErrorInfo = NULL; >+ COM_CurrentInfo()->errorinfo = NULL; > return S_OK; > } > >@@ -506,18 +507,16 @@ HRESULT WINAPI GetErrorInfo(ULONG dwRese > HRESULT WINAPI SetErrorInfo(ULONG dwReserved, IErrorInfo *perrinfo) > { > IErrorInfo * pei; >- APARTMENT * apt = COM_CurrentInfo(); > > TRACE("(%ld, %p)\n", dwReserved, perrinfo); > >- if (!apt) apt = COM_CreateApartment(COINIT_UNINITIALIZED); >- > /* release old errorinfo */ >- pei = (IErrorInfo*)apt->ErrorInfo; >- if(pei) IErrorInfo_Release(pei); >+ pei = COM_CurrentInfo()->errorinfo; >+ if (pei) IErrorInfo_Release(pei); > > /* set to new value */ >- apt->ErrorInfo = perrinfo; >- if(perrinfo) IErrorInfo_AddRef(perrinfo); >+ COM_CurrentInfo()->errorinfo = perrinfo; >+ if (perrinfo) IErrorInfo_AddRef(perrinfo); >+ > return S_OK; > } >--- dlls/ole32/marshal.c (revision 67) >+++ dlls/ole32/marshal.c (local) >@@ -109,9 +109,13 @@ static HRESULT register_ifstub(wine_mars > } > else > { >- TRACE("constructing new stub manager\n"); >+ struct apartment *apt; > >- manager = new_stub_manager(COM_ApartmentFromOXID(mid->oxid), obj); >+ TRACE("constructing new stub manager\n"); >+ >+ apt = COM_ApartmentFromOXID(mid->oxid, TRUE); >+ manager = new_stub_manager(apt, obj); >+ COM_ApartmentRelease(apt); > if (!manager) return E_OUTOFMEMORY; > > if (!tablemarshal) stub_manager_ref(manager, 1); >--- dlls/ole32/rpc.c (revision 67) >+++ dlls/ole32/rpc.c (local) >@@ -308,8 +308,6 @@ PipeBuf_Release(LPRPCCHANNELBUFFER iface > if (ref) > return ref; > >- FIXME("Free all stuff\n"); >- > memcpy(&header.mid, &This->mid, sizeof(wine_marshal_id)); > > pipe = PIPE_FindByMID(&This->mid); >@@ -892,7 +890,7 @@ static DWORD WINAPI apartment_listener_t > HANDLE listenPipe; > APARTMENT *apt = (APARTMENT *) param; > >- /* we must join the marshalling threads apartment */ >+ /* we must join the marshalling threads apartment. we already have a ref here */ > NtCurrentTeb()->ReservedForOle = apt; > > sprintf(pipefn,OLESTUBMGR"_%08lx%08lx", (DWORD)(apt->oxid >> 32), (DWORD)(apt->oxid)); >@@ -926,7 +924,7 @@ static DWORD WINAPI apartment_listener_t > void start_apartment_listener_thread() > { > APARTMENT *apt = COM_CurrentApt(); >- >+ > assert( apt ); > > TRACE("apt->listenertid=%ld\n", apt->listenertid); >--- dlls/ole32/stubmanager.c (revision 67) >+++ dlls/ole32/stubmanager.c (local) >@@ -41,6 +41,7 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(ole); > >+/* this refs the apartment on success, otherwise there is no ref */ > struct stub_manager *new_stub_manager(APARTMENT *apt, IUnknown *object) > { > struct stub_manager *sm; >@@ -71,6 +72,7 @@ struct stub_manager *new_stub_manager(AP > list_add_head(&apt->stubmgrs, &sm->entry); > LeaveCriticalSection(&apt->cs); > >+ COM_ApartmentAddRef(apt); > TRACE("Created new stub manager (oid=%s) at %p for object with IUnknown %p\n", wine_dbgstr_longlong(sm->oid), sm, object); > > return sm; >@@ -82,7 +84,7 @@ struct stub_manager *get_stub_manager_fr > struct list *cursor; > APARTMENT *apt; > >- if (!(apt = COM_ApartmentFromOXID(oxid))) >+ if (!(apt = COM_ApartmentFromOXID(oxid, TRUE))) > { > WARN("Could not map OXID %s to apartment object\n", wine_dbgstr_longlong(oxid)); > return NULL; >@@ -101,6 +103,8 @@ struct stub_manager *get_stub_manager_fr > } > LeaveCriticalSection(&apt->cs); > >+ COM_ApartmentRelease(apt); >+ > TRACE("found %p from object %p\n", result, object); > > return result; >@@ -112,14 +116,13 @@ struct stub_manager *get_stub_manager(OX > struct list *cursor; > APARTMENT *apt; > >- if (!(apt = COM_ApartmentFromOXID(oxid))) >+ if (!(apt = COM_ApartmentFromOXID(oxid, TRUE))) > { > WARN("Could not map OXID %s to apartment object\n", wine_dbgstr_longlong(oxid)); > return NULL; > } > > EnterCriticalSection(&apt->cs); >- > LIST_FOR_EACH( cursor, &apt->stubmgrs ) > { > struct stub_manager *m = LIST_ENTRY( cursor, struct stub_manager, entry ); >@@ -130,9 +133,10 @@ struct stub_manager *get_stub_manager(OX > break; > } > } >- > LeaveCriticalSection(&apt->cs); > >+ COM_ApartmentRelease(apt); >+ > TRACE("found %p from oid %s\n", result, wine_dbgstr_longlong(oid)); > > return result; > > Rob

3 6

Re: [QUARTZ] Use Interlocked* functions in AddRef and Release (RESEND)
by Alexandre Julliard 04 Jan '05

04 Jan '05

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > TRACE("(%p)->()\n", iface); > - if (!--This->refCount) > + if (!InterlockedDecrement(&This->refCount)) > { > CoTaskMemFree(This->ppFilters); > CoTaskMemFree(This); You also need to store the result of the decrement and have the function return that value instead of This->refCount, otherwise it's still not thread-safe. -- Alexandre Julliard julliard(a)winehq.org

2 1

Mandrake packages
by Mike Hearn 04 Jan '05

04 Jan '05

Hi, The downloads page advertises support for 10.1, 10.0 and 9.2 Mandrake packages but it seems only 10.1 RPMs are provided. Should the download page be updated to say only 10.1 is available? I'd rather actually it was built on an older Mandrake and then fixed to work on later versions too if that was necessary, as I suspect the only real difference is glibc symvers. thanks -mike

2 1

Re: Change some d3d9 RACE( "stub ") into FIXME ("stub")
by Lionel Ulmer 04 Jan '05

04 Jan '05

On Tue, Jan 04, 2005 at 05:21:41PM +0000, Mike Hearn wrote: > One thing to be aware of when doing this is that some of these calls may > be used very frequently, and the cost of outputting a fixme for each one > is high. Because TRACEs are not output by default making a stub a TRACE is > often used in this situation. Not to mention the users who will generate bug reports saying 'look it does not work because of this FIXME' whereas this FIXME is just for an obscure function which does not do anything important and can be let as a stub for ages. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: Native unix style paths in wine common dialogs
by Mike Hearn 04 Jan '05

04 Jan '05

On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. Fantastic! What would rule even more is if this was not a conditional compilation flag, but something that could be toggled at runtime. That way you can have a single Wine installation that has both half-native winelib apps and regular win32 binaries run at once. As it is, this patch is only really useful for when you are distributing your own app-specific copy of Wine, no? > Btw, if anyone is interested we also have another module which > can be used to convert the windows-style drive letters returned > by the common dialogs into unix-style paths (if you want to use > these paths will "normal" file i/o functions such as C++ stream i/o). Isn't that what wine_get_unix_file_name does? thanks -mike

2 1

Re: keybd_event patch and default combobox height patch
by tony_lambregts＠telusplanet.net 04 Jan '05

04 Jan '05

Peter Hercek wrote: > server/queue.c > Fixes an error in keybd_event function. This function sends events even > between different processes on win32. This was not handled in wine. > > dlls/user/combo.c > The default size for comboxes was 2 pixels bigger in wine at the > standard dpi. > > The patches are against wine 20041019. > > Index: server/queue.c > =================================================================== > --- server/queue.c (revision 29655) > +++ server/queue.c (working copy) > @@ -1073,6 +1073,8 @@ > *msg_code = msg->msg; > if (is_keyboard_msg( msg )) > { > + if (!input || !(input->focus) || !(input->active)) > + input = foreground_input; > if (input && !(win = input->focus)) > { > win = input->active; > Index: dlls/user/combo.c > =================================================================== > --- dlls/user/combo.c (revision 29655) > +++ dlls/user/combo.c (working copy) > @@ -207,8 +207,10 @@ > * The height of the text area is set in two ways. > * It can be set explicitly through a combobox message or through a > * WM_MEASUREITEM callback. > - * If this is not the case, the height is set to 13 dialog units. > - * This height was determined through experimentation. > + * If this is not the case, the height is set to 12 dialog units. > + * This height was determined through experimentation. It was > + * set to 13 originally but this led to higher comboboxes than > + * in windows. > */ > static INT CBGetTextAreaHeight( > HWND hwnd, > @@ -239,7 +241,7 @@ > > ReleaseDC(hwnd, hDC); > > - iTextItemHeight = ((13 * baseUnitY) / 8); > + iTextItemHeight = ((12 * baseUnitY) / 8); > > /* > * This "formula" calculates the height of the complete control. > > These should have been sent as two separate patches. since they address two different issues. -- Tony Lambregts

1 0

Changed files to use interlocked functions
by Paul Vriens 04 Jan '05

04 Jan '05

Hi, the Janitorial page shows that the "Use Interlocked functions in AddRef and Release methods" project is finished. There are however several files (at least 135) that still use the non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some ole/oleaut32. Do they still need to be changed ? Cheers, Paul.

4 5

Re: gdi/tests/metafile.c NT 4 fix
by Dmitry Timoshkov 04 Jan '05

04 Jan '05

"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > --- dlls/gdi/tests/metafile.c 27 Dec 2004 17:46:36 -0000 1.4 > +++ dlls/gdi/tests/metafile.c 3 Jan 2005 14:27:55 -0000 > @@ -185,8 +185,6 @@ > ret = EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc); > ok( ret, "EnumEnhMetaFile error %ld\n", GetLastError()); > > - ok(emr_processed, "EnumEnhMetaFile couldn't find EMR_EXTTEXTOUTA or EMR_EXTTEXTOUTW record\n"); > - This defeats the whole purpose of the test, could you investigate what is going on? -- Dmitry.

2 1

Re: [LOSTWAGES] Add a short blurb about what Wine is on the About page
by Tom 04 Jan '05

04 Jan '05

Mike McCormack wrote: > > Index: templates/en/about.template > =================================================================== > RCS file: /home/wine/lostwages/templates/en/about.template,v > retrieving revision 1.15 > diff -u -r1.15 about.template > --- templates/en/about.template 1 Dec 2004 22:15:11 -0000 1.15 > +++ templates/en/about.template 4 Jan 2005 07:32:05 -0000 > @@ -4,6 +4,12 @@ > > <h1>About Wine</h1> > > +<p>Wine is a translation layer (a program loader) capable of running > +Windows applications on Linux and other POSIX compatible operating > +systems. Windows programs running in Wine act as native programs would, > +running without the performance or memory usage penalties of an emulator, > +with a similar look and feel as other your desktop.</p> What about: with a similar look and feel as other applications on your desktop. Tom

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel