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

Re: video4linux - wine
by luis lenders Jan. 5, 2005

Jan. 5, 2005

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. Actually video4linux has quite some capabilities, a program like xawtv for example can even grab a movie from your tv-tuner card. >> 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....? Altough I'm a programming noob i tried a few weeks ago to write some code to accomplish this with (not much) but still a little succes: i used code from a program like vidcat to read a frame from my v4l device (in png format), used code from another program (png2bmp) to turn it into a bitmap, and used CreateWindowEx to display this in a windowsprogram under wine. Although the window with the frame from my webcam showed up , the windowsprogram did not behave further as it should do. There is plenty of code to be found on the internet using the v4l api, but the problem how to get this in wine. Maybe someone has some further hints? Regards luis ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

3 2

Problem with builtin and native regedit
by Christian Costa Jan. 5, 2005

Jan. 5, 2005

Hi, When I try to renamed a key with the builtin regedit, all subkeys are lost. The problem is in regedit because the native one works. The latter however crash just after the renaming. See below for the backtrace. Any idea ? Bye, Christian fixme:font:load_VDMX No suitable ratio found fixme:font:load_VDMX No suitable ratio found fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:menu:TrackPopupMenuEx not fully implemented First chance exception: page fault on write access to 0x00300039 in 32-bit code (0x401fe6dc). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0007 EIP:401fe6dc ESP:406cf244 EBP:406cf25c EFLAGS:00010202( - 00 - -RI1) EAX:40350038 EBX:402341e4 ECX:406cf24c EDX:0030002d ESI:403cb838 EDI:00000020 Stack dump: 0x406cf244: 00000000 40350000 40350000 4085a094 0x406cf254: 40350000 00000001 406cf27c 40843ad8 0x406cf264: 40350000 00000002 0000001c 4085a094 0x406cf274: 403637fa 00000000 406cf294 40843b8d 0x406cf284: 00000001 000012ee 4085a094 40859f3a 0x406cf294: 406cf2b4 408445be 00000001 00000001 0200: sel=1007 base=40015000 limit=00001f97 32-bit rw- Backtrace: =>1 0x401fe6dc RtlAllocateHeap+0x8c(heap=0x40350000, flags=0x2, size=0x1c) [heap.c:1128] in ntdll (0x 406cf25c) 2 0x40843ad8 REGION_AllocWineRegion+0x28(n=0x1) [/home/titan/winecvs/wine/dlls/gdi/../../include/wi nbase.h:2130] in gdi32 (0x406cf27c) 3 0x40843b8d REGION_CreateRegion+0x3d(n=0x1) [/home/titan/winecvs/wine/dlls/gdi/region.c:521] in gd i32 (0x406cf294) 4 0x408445be ExtCreateRegion+0x4e(lpXform=0x0, dwCount=0x100, rgndata=0x403cd008) [/home/titan/wine cvs/wine/dlls/gdi/region.c:1013] in gdi32 (0x406cf2b4) 5 0x40cd4f33 get_server_visible_region+0x103(hwnd=0x4002e, top=0x10020, flags=0x10012) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:114] in x11drv (0x406cf350) 6 0x40cd53b2 X11DRV_GetDC+0x182(hwnd=0x4002e, hdc=0x7b0, hrgn=0x0, flags=0x10012) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:323] in x11drv (0x406cf3a0) 7 0x40717f15 GetDCEx+0x325(hwnd=0x4002e, hrgnClip=0x0, flags=0x10000) [/home/titan/winecvs/wine/dlls/user/../../windows/dce.c:438] in user32 (0x406cf3d8) 8 0x4073e9e4 CARET_DisplayCaret+0x24(hwnd=0x4002e, r=0x406cf488) [caret.c:58] in user32 (0x406cf400) 9 0x4073f28b HideCaret+0x11b(hwnd=0x4002e) [/home/titan/winecvs/wine/dlls/user/../../include/winbase.h:2125] in user32 (0x406cf4a4) 10 0x40cd67e8 X11DRV_SetWindowPos+0x238(winpos=0x406cf4f4) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:862] in x11drv (0x406cf4e8) 11 0x40736188 SetWindowPos+0xe8(hwnd=0x4002e, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x97) [/home/titan/winecvs/wine/dlls/user/../../windows/winpos.c:1225] in user32 (0x406cf520) 12 0x40cd6dee X11DRV_ShowWindow+0xce(hwnd=0x4002e, cmd=0x0) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:1139] in x11drv (0x406cf56c) 13 0x40735637 ShowWindow+0x67(hwnd=0x4002e, cmd=0x0) [/home/titan/winecvs/wine/dlls/user/../../windows/winpos.c:864] in user32 (0x406cf588) 14 0x40b08edf TREEVIEW_EndEditLabelNow+0x14f(infoPtr=0x403b42f0, bCancel=0x0) [/home/titan/winecvs/wine/dlls/comctl32/treeview.c:3695] in comctl32 (0x406cfdf4) 15 0x40b0884d TREEVIEW_Edit_SubclassProc+0xad(hwnd=0x4002e, uMsg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/comctl32/treeview.c:3450] in comctl32 (0x406cfe10) 16 0x40736937 WINPROC_wrapper+0x17 in user32 (0x406cfe34) 17 0x40736c71 WINPROC_CallWndProc+0x51(proc=0x40b087a0, hwnd=0x4002e, msg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/user/../../windows/winproc.c:421] in user32 (0x406cfe60) 18 0x4073bf95 WINPROC_CallProc32ATo32W+0x55(func=0x40b087a0, hwnd=0x4002e, msg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/user/../../windows/winproc.c:2930] in user32 (0x406cfe88) 19 0x4073c9c5 CallWindowProcA+0x95(func=0x407d7d30, hwnd=0x4002e, msg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/user/../../windows/winproc.c:3221] in user32 (0x406cfebc) 20 0x407256d6 DispatchMessageA+0xd6(msg=0x406cff10) [/home/titan/winecvs/wine/dlls/user/../../windows/message.c:795] in user32 (0x406cfef8) 21 0x0040b87a EntryPoint+0x133 in regedit (0x406cff2c) 22 0x404d76a8 start_process+0xc8(arg=0x0) [/home/titan/winecvs/wine/dlls/kernel/process.c:1046] in kernel32 (0x406cfff4) 23 0x4002adad wine_pthread_abort_thread+0x2d(status=0x0) [port.c:85] in libwine.so.1 (0x00000000) 0x401fe6dc RtlAllocateHeap+0x8c [heap.c:1128] in ntdll: movl %eax,0xc(%edx)

1 0

Trying to get rid of gdi.h
by Rémi Assailly Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

2 2

question about the status of the wine printing system
by Udo Rader Jan. 5, 2005

Jan. 5, 2005

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) Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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 Jan. 5, 2005

Jan. 5, 2005

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. Jan. 5, 2005

Jan. 5, 2005

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

1 0

wineserver: fix get_update_region for desktop window
by Michael Jung Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

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 Jan. 4, 2005

Jan. 4, 2005

"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 Jan. 4, 2005

Jan. 4, 2005

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

Re: build problem on current cvs [fixed]
by Dan Kegel Jan. 4, 2005

Jan. 4, 2005

Jack wrote in http://www.winehq.org/hypermail/wine-devel/2004/12/0720.html : >>Program received signal SIGSEGV, Segmentation fault. >>0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >>(gdb) bt >>#0 0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >>#1 0x4009d06c in malloc () from /lib/i686/libc.so.6 >>#2 0x080525a0 in pp_xmalloc (size=11) at ../../../wine/libs/wpp/preproc.c:80 >>#3 0x0805264a in pp_xstrdup (str=0xbfffec68 "\"11:25:54\"") >> at ../../../wine/libs/wpp/preproc.c:108 >> >> > It is probably caused by overwritting the allocated memory. The last > changes of widl look well so I think it is > some old hidden problem. Lookng at code I found a potential bug, but I'm > not sure if it a bug. In parsers, > both widl's and wpp's, strings are not duplicated whie adding to > structures. If it helps, I'll see if it is correct at all. > This is included in diffs: wppppy.diff and widl.diff. Could you try it? > I also found another small bug in wpp, but > it's not what we're looking for. I included it with some code cleanup in > wpppreproc.diff. I swear I found this same error several months ago, but never submitted a patch (and can't find my old patch now). Your three patches solved the widl crash in current cvs for me. Alexandre, can you review / apply them? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Should we get rid of the wine-license list?
by Scott Ritchie Jan. 3, 2005

Jan. 3, 2005

Looking at the archives it appears that wine-license has had very little traffic, to the point where a lot of it is probably not being read when it comes up, since people like me are not subscribed to that list. It seems like a lot of the stuff being sent there should instead go to wine-devel. Thoughts? Scott Ritchie

7 7

Hyperthreading and SMP
by Kenneth Porter Jan. 3, 2005

Jan. 3, 2005

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

2 4

spy.c in debug output
by Vitaly Lipatov Jan. 3, 2005

Jan. 3, 2005

Can anyone tell me why we can't use functions from windows/spy.c for debugging purposes (in TRACE output) in any dlls/ modules? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

5 8

Re: USER32: result of ScrollBar functions review
by Dmitry Timoshkov Jan. 3, 2005

Jan. 3, 2005

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > +/* New Scrollbar info since Windows 98, Windows NT 4.0 with SP6 */ > +typedef struct tagSCROLLBARINFO > +{ > + DWORD cbSize; /* Size of SCROLLBARINFO struct */ ... > +BOOL WINAPI GetScrollBarInfo(HWND hwnd, LONG idObject, LPSCROLLBARINFO psbi) > +{ > + RECT rect; > + INT arrowSize, thumbSize, thumbPos, nBar, vertical; > + FIXME("check me"); > + if (psbi->cbSize != sizeof(RECT)) > + return FALSE; Why are you testing psbi->cbSize for sizeof(RECT) here? -- Dmitry.

2 1

Lostwages updates
by Scott Ritchie Jan. 3, 2005

Jan. 3, 2005

There have been a few patches submitted to lostwages over the past few weeks that are still uncommitted. Are you still on vacation Jeremy? Should we resend? Thanks, Scott Ritchie

3 2

Re: convert TCM_ messages (dec->hex)
by Dmitry Timoshkov Jan. 3, 2005

Jan. 3, 2005

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > As we have debug printing of messages in hex format > and can't use SPY_GetMsgName for their human readable output > I replace decimal const by their hex values I'd suggest to make debug output look like (TCM_FIRST + decimal) instead of making Wine headers hard to read. -- Dmitry.

1 0

Re: Support for running Winelib apps directly
by Boaz Harrosh Jan. 3, 2005

Jan. 3, 2005

Vincent Béron wrote: >Remove the loader script from Winelib apps. Winelib apps are still .so >files, but they can be launched directly now. > > > We did try to keep up with what wineapploader and wine did to load a fake-dll winelib app and all the spec.c magic that linked it all. Could you please elaborate a bit on what has changed and how it is all glued together? Is the embedded wineapploader Process reused for the main process for easier debugging? Currently when you debug a winelib app under GDB you cannot use wineapploader you need to use wine-kthread/pthread directly, and disable execshild and friends all together. Will that be at all possible now? Do you think it can be easier now for a: let's call it Unix app, to become a winelib application mid-flight. Lets say, when it wants to load a PE plug in DLL. (The way of mono and that Audio program can't recall the name). Could a UnixODBC (elf dynamic lib) force a load on a PE ODBC driver, therefor making the running app a winelib, Like PHP for example? If so could you make a little hello-world example of how it is done? Grate work Free Life Boaz

2 1

December 2004 - more patches than you can shake a stick at
by Mike Hearn Jan. 3, 2005

Jan. 3, 2005

Happy new year everybody! Being the patch fetishist that I am, I couldn't help noticing that in December 2004 we cleared 8mb of patches: that's by far the largest since the current archives began in October 2000. The extra traffic came from a lot of places: - Huge improvements to the Application Database. - The number was also pushed higher by an MSI merge from CodeWeavers. - Some big janitorial patches went in from Michael Stefaniuc - Finally Rob and I were cranking out DCOM patches, and there are of course lots more in the pipeline. Now time for some crystal ball gazing. Here are some interesting patches we might be seeing in 2005: - Completion of the WM rewrite work. Alexandre seems to be making great progress on this, which will let us fix many of the odd visual corruption problems we've been plagued with for so long. It'll also let us remerge Alexs winedesktop patch, giving us a real desktop window that is used for all apps, at last. It should have many other benefits too: fixing the flickering in the Half Life menus and allowing us to support the NETWM fullscreen protocol. This should let us resolve many instances of the "my game starts but I can't type" problem. - Lots more DCOM code. Huw Davies is hacking on getting widl to produce a stdole32.tlb file, once that's in we can start really nailing InstallShield to the wall. We will hopefully get this and the thread-affinity patches in the next few months, which should mean for the first time we can run InstallShield 6 installers perfectly, out of the box. Support for newer InstallShields will come as time permits of course. - More MSI improvements! CodeWeavers are continuing to work on this so it should develop nicely even though the iTunes installer work has been completed. Office 2003 will also motivate this. It's being used by at least one commercial app porting project as well. - Support for running Winelib apps directly, so we can get rid of the .exe.so extensions/shell wrapper scripts, and produce "raw" ELF binaries. They'll still need the wine loader app to be present of course, but it should all be invisible and behind the scenes. Vincent Beron and I have been working on this in the last week or so, and we just need to finish it off and convince Alexandre the extra assembly is worth it! :) Who knows what the new year will bring? More apps working out of the box, that's for sure! Have fun! thanks -mike

4 5

Re: Support for running Winelib apps directly
by Boaz Harrosh Jan. 3, 2005

Jan. 3, 2005

Vincent Béron wrote: >Remove the loader script from Winelib apps. Winelib apps are still .so >files, but they can be launched directly now. > > > We did try to keep up with what wineapploader and wine did to load a fake-dll winelib app and all the spec.c magic that linked it all. Could you please elaborate a bit on what has changed and how it is all glued together? Is the embedded wineapploader Process reused for the main process for easier debugging? Currently when you debug a winelib app under GDB you cannot use wineapploader you need to use wine-kthread/pthread directly, and disable execshild and friends all together. Will that be at all possible now? Do you think it can be easier now for a: let's call it Unix app, to become a winelib application mid-flight. Lets say, when it wants to load a PE plug in DLL. (The way of mono and that Audio program can't recall the name). Could a UnixODBC (elf dynamic lib) force a load on a PE ODBC driver, therefor making the running app a winelib, Like PHP for example? If so could you make a little hello-world example of how it is done? Grate work Free Life Boaz

1 0

Approving of the WINEprobe initiative
by David Gümbel Jan. 2, 2005

Jan. 2, 2005

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

8 14

`__ctype_b' .. `__ctype_toupper'
by Dietrich Teickner Jan. 2, 2005

Jan. 2, 2005

Hi, I have updated to suse 9.1. After them I have this error. Where must be this definitions ? Dietrich ../../libs/libwpp.a(y.tab.o)(.text+0x2827): In function `combine_mtext': /home/sao2l02/Wine/wine/libs/wpp/./ppy.y:626: undefined reference to `__ctype_b' ... ../../libs/libwpp.a(lex.yy.o)(.text+0x3051):/home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1078: undefined reference to `__ctype_b' ../../libs/libwpp.a(lex.yy.o)(.text+0x3bfe): In function `is_c_h_include': /home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1411: undefined reference to `__ctype_toupper' collect2: ld returned 1 exit status make[2]: *** [widl] Fehler 1 make[1]: *** [widl] Fehler 2 make: *** [tools] Fehler 2

3 2

Re: oleaut.c small change to former patch an some more
by Marcus Meissner Jan. 2, 2005

Jan. 2, 2005

On Sat, Jan 01, 2005 at 04:25:34PM +0100, Dietrich Teickner wrote: > Hi Alexandre, > > I have some problems with SysReAllocStringLen in Odin(wine for os/2) and > the win32 MySqlQueryBrowser.exe. And I thing wine will have some times > the same. I thing we can / need no memcpy, if str and old the same > before realloc. We can reset the source (str) to NULL in this case. This > should solve the problem for wine and odin. While we do not really need memcpy here, I think we should understand the real problem you see. Is there any problem? What exactly is not working? (explaining what you do in Mysqlquerybrowser is ok, I have it running here.) Your patch would not handle a potential truncation if the "len" parameter is changed, right? Can you provide a testcase snippet for dlls/oleaut32/tests/vartype.c::test_SysReAllocStringLen() that shows different behaviour between real Windows and WINE? Ciao, Marcus

1 0

loading native binaries
by Ivan Leo Puoti Jan. 1, 2005

Jan. 1, 2005

Alexandre, your patch doesn't perform relocation, and this causes and access violation in secdrv.sys To perform relocation, we need to be able to write to memory, but there appears to be some sort of problem with this that causes wine to hang. I'm attaching your original patch, plus an updated one that Laurent Pinchar and I have come up with, it should work *in theory*, but it doesn't. Laurent has suggested that maybe it would if the image was aligned to a page boundary, but I'm to tired to look into it now. I'm cc'ing wine-devel, ideas/patches welcome. Ivan.

1 0

Re: Remove heap.h
by Jon Griffiths Jan. 1, 2005

Jan. 1, 2005

Hi, >>+ docA.lpszDocName = WtoA( doc->lpszDocName ); >>+ docA.lpszOutput = WtoA( doc->lpszOutput ); >>+ docA.lpszDatatype = WtoA( doc->lpszDatatype; >> >Isn't there a missing parenthesis? There sure is, I must have deleted it while removing the cruft from the diff (since it compiles fine on my box at home :). I'll resubmit. (Dimitrie) >Because in 99.99% of cases you don't want to convert from W->A. >If all our functions are Unicode, a W->A conversion is a warning >sign, and for sure you wouldn't want to encourage people to do >so by making it any easier. winapi_check will allready tell us all cross-calls anyway, doesn't it? It may be years before all the a to w conversions are done and we are 100% internally unicode, why live with a non standard header that long? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Jumbo Mail - fireworks
by puoti＠inwind.it Jan. 1, 2005

Jan. 1, 2005

Ciao, questa è una Jumbo Mail, che puoti(a)inwind.it ti ha inviato per condividere con te * video.zip (119256515 byte) e questo messaggio: -------------------------------------------------------------------------------- Greetings and Happy New Year from the Sorrento Peninsular. I've just finished taking this film of the New Year firework celebrations still going on all around. I took this film from our terrace, I hope you enjoy it. The file is big, 113MBs, so I don't recommend downloading it if you don't have broadband. The download link will expire in 7 days. Happy New year to all, Ivan. -------------------------------------------------------------------------------- Per scaricare questi files fai click sul seguente link: http://webmail.inwind.it/r.php?d=inwind.it&wr=_unreg_4eh3943v&ws=3850nl9t&e… Ti ricordiamo che questo link sarà valido fino al 08.01.2005 alle 07:23. Jumbo Mail è il servizio di Libero Mail che permette di condividere file di grandi dimensioni fino a 1GB, senza problemi di superamento dei limiti delle caselle e-mail. Scopri come è semplice e veloce inviare una Jumbo Mail! Fai click su http://liberomail.libero.it/jumbomail.phtml Lo staff di Libero

1 0