- wine-devel - winehq.org

[Fwd: Problems installing IE6]
by Joaquín Fernández 29 Sep '04

29 Sep '04

Hello I am trying to install IE6 in wine but i can't. When the installer is over 70% then stop and not advance. I have made a clean fake disk the three times, i probed with WINEDLLOVERRIDES for each dll used by IE installation, i use winedebug for seeking an error but no error, the installer is refreshing the windows without errors but don't advance. I am using wine version 20040914 from CVS compiled in Mandrake 10.0 with cooker updates. I am not using config file because the wineprefixcreate don't make the file and i have seen that wine use now several parameters in the registry. I tryied the 3 methods in frankscorner.org but nothing, the first method using a script can't install it. When i probed the second and third method i made a simple config file with [Version] & [DllOverrides] sections only, but nothing, the program don't terminate the installation, stop after 70% (the % change between intents:70,73,76,81,96, etc) and only refresh the screen (i suppose that because the labels in form are blinking). Somebody can help me? Joaquín P.D.: I don't need IE6 but i need MDAC and MDAC need IE>=4. If somebody know how to install DAO components without installing IE, i am interested in a reply. -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

4 9

Re: Progress Bar: Fix Class Style & Repainting (resend2)
by Alexandre Julliard 29 Sep '04

29 Sep '04

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > - Fix class style to include the hbrBackground member. > - Fix repainting issues introduced by this change. > - Add WM_ERASEBKGND handler and remove background drawing code from > the WM_PAINT handler. Isn't that going to cause a lot of flicker? This was the reason for the existing code, because otherwise it looks really bad with apps that update the progress bar a lot. -- Alexandre Julliard julliard(a)winehq.org

4 5

Re: Upgrade management
by Mike Hearn 29 Sep '04

29 Sep '04

[CCd wine-devel as I think you meant it to go there originally] Holly Bostick wrote: > Seems to me that whether or not 99% of users will forget is not your > responsibility as developers. Other than making very sure that users > know there is something to remember, further programming against the > possibility that they will forget what you told them not to is more work > for you, simply in order to absolve them of responsibility for their own > system and make things "look good" at all times to those who want > everything "click and run". > > Look at the problems that attitude (and the compensatory measures to > resolve it) has caused Microsoft. I would think that you all have better > things to do with your valuable development time-- namely developing the > actual application, not babysitting me (the user with the mind like a > sieve). Well, there are a couple of good reasons why automatic upgrades are good for us developers: 1) If we don't, we'll just get bug reports due to people not having full upgrades: we already get plenty of bizarre bug reports due to broken packaging, last thing we need is for people to fill bugzilla with even more. And yes some developers do tech support :) 2) We already do a ton of stuff automatically, and nobody ever notices. This strongly implies that automatic setup and configuration does benefit people: I can assure you they noticed when we didn't set up the wine config upstream! We want Wine to have a good reputation for reliability, but currently it doesn't - people run random Foo app, it crashes and burns maybe due to incorrect configuration and they walk away saying "Oh well, Wine is crap, what did I expect?". This happens quite a bit. Ensuring the user is cleanly and transparently upgraded makes things Just Work to a greater extent, which is good for everybody. I'm still not hugely convinced about the backup thing: if you want to back up your configuration before upgrading Wine it's very easy: cp -rv ~/.wine ~/.wine.old ... we could even do that as part of the upgrade process. Possibly we should back up the registry, but not the virtual drive C. The C drive is going to change a lot less than the registry will: a Wine upgrade typically means new DLLs and maybe new registry contents. It rarely means changes to the drive layout. thanks -mike

1 0

How to deal with C++ APIs in wine spec file
by Jia L Wu 29 Sep '04

29 Sep '04

Hi, I have to write a spec file so that a winelib application can use a third party dll. The problem is that APIs in third party dll are written in C++. As c++ names and parameters are mangled, how can i call them in spec file? For example, how can I call a class constructor (which is built form another class) in spec file? Can anyone provide me an example? Thanks. Wu

1 0

Re: Moved some local variables from StartServiceCtrlDispatcherA/W to service environment block
by Alexandre Julliard 29 Sep '04

29 Sep '04

"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes: > ChangeLog: > > Moved some local variables from StartServiceCtrlDispatcherA/W to service environment block. > Introduced helper function service_ctrl_dispatcher. I don't think you want to pass ASCII strings across processes, there's no guarantee that both processes are using the same codepage. Inter-process communication should always be done in Unicode. -- Alexandre Julliard julliard(a)winehq.org

2 1

Updated winecfg to do list
by Mike Hearn 29 Sep '04

29 Sep '04

OK, well assuming that Alexandre commits the last of my patches to winecfg at some point (I suspect there is a reason they aren't already ...), here is the updated todo list for winecfg based on my last email on the subject: http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html I'm probably not going to do any more work on winecfg for a while. > You probably want to increase the size of the drive mappings list so it > fills the tab, currently there is just a lot of empty space at the top of > the pane now you removed the old stuff. If AJ commits the last two patches, this is done. In fact, the editing has been moved into the main tab, as there isn't much reason to have a separate window for this and it simplifies the UI and code somewhat. > Also we should kill the autodetect button. This is done by > wineprefixcreate these days, or should be. Getting there ... drive autodetection is implemented. The heuristics could perhaps be improved but they'll do for now. But, we need to call it from wineprefixcreate. This means adding code like so to main(): if (argv[0] is "--drive-detect") { gui_mode = FALSE; auto_detect_drives(); return apply_drive_changes(); } > - Drive editing seems broken. The list box only updates the second time I > hit edit. err:winecfg:applyDriveChanges unable to set volume label for > devicename of 'H:\', label of '' With my last two patches, this works for me. > - Browse in the "Add/Edit drive" dialog is a WRITEME Oh hum, good point. I suspect this still does nothing, I don't remember. We need to make sure / is mapped (there is a function to do this in drivedetect.c), trigger the shell directory select dialog, then if we had to map / automatically, unmap it again. Not too hard to implement. We can probably slide this for 0.9, it's not essential. > - Build system isn't right: I did a cvs update but the res files weren't > recreated properly. I had to do a make clean to get the gui updates. Probably my [ab]uses of make depend, can be ignored. > - "Add Application" has poor usability: we always use a file browser > dialog box even though the most common use case is just "foo.exe", ie > the user knows the name and doesn't care about the location. Worse we > start in the c:\windows\desktop folder for some reason, meaning users > might accidentally select a .lnk file! Well, we still use a file open dialog but at least it starts in c:\ now and is filtered on EXE files. If somebody wants to implement a natty dialog like the GNOME run window, go for it! This would be a nice usability improvement, especially if you implemented then used listview tile mode. > - The Add/Remove application buttons are *way* too big! Fixed > - Obviously, once audio autodetection has been moved into the drivers we > need to kill the audio tab. Still needs to be done. Not all that hard. > - Libraries tab just has generally poor usability, actually. The first > item in the radio group is "Builtin" meaning that's the one users are > most likely to select, it should be "builtin, native" followed by "native, > builtin" Lots of tweaks to this tab, I find it a lot more convenient to work with now. The main remaining problem is that enter always triggers OK in the applet itself, and when you're typing in a new DLL you want to add, you want enter to add it not close the window! Not sure how to fix this without messing up the property sheet API. > - We ask the user to understand a magic * symbol to set the default - what > is up with that? Fixed. > - There are no helpful default entries in the drop down box for setting a > DLL override, and when you add one the tree does not expand so to actually > *set* it you have to expand the tree then select the new override. It doesn't use a treeview anymore, but the combo box could definitely use some of the most common entries to give people a hint. > - We have way too many (eg, more than zero) tree controls in this app. Fixed. This simplifies the code enormously. I don't think there's really any problem with selecting the app you want to edit on the first tab and it means there aren't any wierd states anymore where you can have a selection in the treeview that doesn't actually mean anything. The titlebar now reflects the app you're editing. > - Drive mappings list is really unclear, there's no separation between the > "Drive X:" label and the unix path its mapped to. This is improved a bit now too but really I'd like to see us use the listview control with a header control here. So in summary the BIG things we need to do before we can consider winecfg good enough for 0.9 are: * Delete the audio tab and use autodetection at wine startup instead * Add a --drive-detect switch and use it from wineprefixcreate * Update the docs to reflect usage of the new tool (Brian is on this) After 0.9 we can look at more UI improvements, importing some artwork to make it prettier, maybe eliminating the property sheet as that's a big pain to work with (though, it may be also that our control is buggy :), and so on. Probably adding more prefs as well, for things like printing and fonts maybe. I'd like to see us get winecfg to some kind of finished, releasable 1.0 state before the end of the year though and then we can mark that task as done on the TODO list. thanks -mike

1 0

Upgrade management
by Mike Hearn 29 Sep '04

29 Sep '04

There are a bunch of different ways we may want to upgrade the users configuration: - Changes to $WINEPREFIX (~/.wine), for example: - Introducing faked DLL headers - Improved drive detection - Changing the way the registry is stored - Adding stuff to the virtual Windows drive - Modifying the registry - Adding new keys - Adding new appdefaults (default config options should be in the code itself). While we have a policy of not having app-specific hacks in Wine, some situations are very hard to resolve without custom overrides. The Internet Explorer installer does a bunch of things we really don't want it to do. The DCOM installer needs custom overrides to convince it to install. And so on. - Registering new COM DLLs (these all boil down to rerunning wine.inf) - Adding new binaries such as fonts, PE DLLs (think Moz AX control), and so on. These may be placed somewhere in the Wine install directory and then symlinked or copied (presumably linked) into drive C. This leads to the following questions: - How do we know when to upgrade the users wineprefix? - How do we avoid disturbing the users configuration? - What implementation do we use to upgrade it? One potential implementation for knowing when to upgrade the wineprefix is to version it in a similar manner to how we version the wineserver protocol: with a simple incrementing integer. This could be stored in the registry, and Wines initialization sequence changed to be: ... Does $WINEPREFIX exist? No, call wineprefixcreate - Continue with startup + Yes? Check the wineprefix version key, if it is < the + version compiled into the source run + "wineprefixcreate --upgrade $oldversion $newversion", which then + performs the upgrade. If it exits with a zero exit code, the + version key is set to the number compiled into the source. + Then continue with startup If registry access is too difficult here, a simpler implementation could be used: just store the number in a .version file. How do we avoid disturbing the users configuration? Alexandre already laid out the plan for this, which is to have HKLM (HKEY_LOCAL_MACHINE) devoted to the defaults we cunningly choose for maximum kewlness, and HKCU (HKEY_CURRENT_USER) is where the users settings are stored. These override the defaults, meaning we can change the default settings by altering wine.inf, then bumping the wineprefix version so triggering a remerge of the default registry contents. This means modifying each piece of code where we read the registry to figure out a user-configurable option. The algorithm becomes: * Check the relevant key in HKCU, if it exists use it * Otherwise, if it's an appdefault, check the same key in HKLM * Otherwise, use the hardcoded default In most cases, there's no point in duplicating the points at which we can control the defaults, doing it in the code is fine. So, it basically means grepping the source to find out where we read settings from, and changing them to use HKCU instead of HKLM, perhaps also reading HKLM depending on the context of the setting (settings that can be used in appdefaults should check both). I don't know how common these settings are but it might be worth having a utility function either in a DLL or inline in a header to do this. Registry code isn't complicated but it is tedious and easy to mess up, so we might as well reduce code duplication at the same time. I think the best implementation is to keep the code responsible for managing WINEPREFIX in wineprefixcreate, and simply extend this program to handle upgrades as well. OK, so the name will be a bit inaccurate but let's not change it - users are already discovering the new program and getting used to it, no need to modify it now especially as it's mostly an internal program. In the above example the old version and new version numbers were passed to wineprefixcreate but most of the time that information wouldn't be needed, for instance if we were to introduce fake DLL headers we could simply check if they already existed and skip that part if so. I think there's no harm in running wine.inf multiple times, so we could just do that every time for both creation and upgrade. I *think* this addresses most of the issues with upgrades, though I'm sure Alexandre can think of more :) Potential unresolved problems: - [How] do we lock wineprefix during upgrade so other processes that are run hang about until it's done? - Currently moving registry keys about is done actually in the code itself: we copy it across then print a message telling the user to delete the old setting manually. There's a fair bit of evidence that some users simply don't spot/understand these warnings. Also, we want to allow people to upgrade Wine with quite long intervals in between yet eventually this code gets deleted. Maybe a better solution is just to have wineprefixcreate understand how to move registry keys around in response to bumping the version. If the script gets too unwieldy, we could split particular upgrades into separate scripts in $prefix/share/wine. - Are there any wierd setups where parts of wineprefix are shared between different users/systems that we need to take into account? Thoughts? Comments? thanks -mike

4 8

WineHQ Downloads Page
by Adam Schreiber 28 Sep '04

28 Sep '04

Could whoever is responsible for updating the website please change the Download page(http://winehq.com/site/download) to read: "Slackware binary .tgz for Slackware" or "Slackware binary .tgz for Slackware 10" The reference to Slackware 9 is confusing users. Thanks, Adam Schreiber -- Why isn't all of your email encrypted? http://gnupg.org http://enigmail.mozdev.org

1 0

Re: urlmon: IInternetSecurityManager
by Mike McCormack 28 Sep '04

28 Sep '04

Huw D M Davies wrote: > Good catch. This classfactory code is fairly pervasive in Wine. I'll > submit a patch fixing all other occurrences of this in a moment. Maybe we should make a new janitorial task to turn all those class factories into singleton into objects too. It's not necessary to allocate a piece of memory at all for a class factory. Mike

4 5

Re: SystemFunction036 debugging problem
by James Hawkins 28 Sep '04

28 Sep '04

> Is this program linking to SystemFunction036 statically or dynamically? I'm not really sure. Is there another way to tell besides doing a trace+all? > If it is linking dynamically (i.e. with GetProcAddresa), one option to try > is to completly remove SystemFunction036 so it is not exported from > advapi32.dll. It might then be that the apps that call it will see that it > is not present and do something else. Actually I just added the stub to advapi32, because the program will crash when it tries to call an umimplemented function. The main problem is that the program is expecting some result from SystemFunction036 (Filip thinks it might be a random generator thing), but it's next to impossible (or so it seems) to implement it correctly without documentation of what it does. I wanted to be able to see which function calls this to see whether I can get in there and keep it from calling. On Tue, 28 Sep 2004 07:01:33 +0800, Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > Is this program linking to SystemFunction036 statically or dynamically? > > If it is linking dynamically (i.e. with GetProcAddresa), one option to try > is to completly remove SystemFunction036 so it is not exported from > advapi32.dll. It might then be that the apps that call it will see that it > is not present and do something else. > > Another option is to try to contact the author of the app in question > (MyPhotoCalendars or whatever it is) and ask them about the function. > > -- James Hawkins

2 1

SystemFunction036 debugging problem
by James Hawkins 28 Sep '04

28 Sep '04

It turns out that SystemFunction036 is actually required to do something for MyPhotoCalendars.exe to install correctly because the installer exits with a program-level exception (ie not wine) What I would like to do is run MyPhot...exe with winedbg and then set a breakpoint for SystemFunction036 so that execution will stop when that function is called so I can see who is calling it or something along those lines, but I set the break point and when SystemFunction036 is called, the program doesnt stop at all. winedbg MyPhotoCalendars.exe WineDbg starting on pid 0xa In 32 bit mode. 1249 static inline void WINAPI DbgBreakPoint(void) { __asm__ __volatile__("int3"); } Wine-dbg>break SystemFunction036 fixme:dbghelp:elf_load_debug_info Unsupported Dwarf2 information for ld-linux.so.2 Breakpoint 1 at 0x4089a670 SystemFunction036 [/home/truiken/wine/dlls/advapi32/crypt.c:1914] in advapi32 Wine-dbg>step 1019 ExitProcess( entry( peb ) ); Wine-dbg>step Single stepping until exit from function, which has no line number information. ......... fixme:crypt:SystemFunction036 ( _A)l@H¦X@`ùm@%!D, 256): stub fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE fixme:crypt:SystemFunction036 (H¦X@, 256): stub fixme:actctx:FindActCtxSectionGuid stub! Invalid address (0x00404aa2) for breakpoint 0, disabling it Invalid address (0x4089a670) for breakpoint 1, disabling it Process of pid=0x0000000a has terminated Wine-dbg>bt You must be attached to a process to run this command. Any thoughts? -- James Hawkins

2 1

missing advapi32 prototype: SystemFunction036
by James Hawkins 28 Sep '04

28 Sep '04

While trying to install MyPhotoCalendars, an exception is raised because of a call to the unimplemented function advapi32.dll.SystemFunction036. >From reading the following post, http://www.winehq.com/hypermail/wine-devel/2003/09/0265.html I can see that it won't be very easy to even stub this function because it's a hidden api. What methods could I use to track down any information about this function or its prototype? -- James Hawkins

4 9

Re: urlmon: IInternetSecurityManager
by Robert Shearman 28 Sep '04

28 Sep '04

Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > Stub implementation of IInternetSecurityManager > Add a classfactory > Fix calling convention of CoInternetCreateSecurityManager > > >+ >+static ULONG WINAPI CF_AddRef(LPCLASSFACTORY iface) { >+ IClassFactoryImpl *This = (IClassFactoryImpl *)iface; >+ return ++(This->ref); >+} >+ > Please try to use Interlocked* functions for ref-counting as it is currently a janitorial task to clean up this type of code and I don't think they are desparate for more work. >+static HRESULT WINAPI CF_CreateInstance(LPCLASSFACTORY iface, LPUNKNOWN pOuter, >+ REFIID riid, LPVOID *ppobj) { >+ IClassFactoryImpl *This = (IClassFactoryImpl *)iface; >+ HRESULT hres; >+ LPUNKNOWN punk; >+ >+ TRACE("(%p)->(%p,%s,%p)\n",This,pOuter,debugstr_guid(riid),ppobj); >+ >+ hres = This->pfnCreateInstance(pOuter, (LPVOID *) &punk); >+ if (FAILED(hres)) { >+ *ppobj = NULL; >+ return hres; >+ } >+ hres = IUnknown_QueryInterface(punk, riid, ppobj); >+ if (FAILED(hres)) { >+ *ppobj = NULL; >+ return hres; > You leak a reference on failure here. >+ } >+ IUnknown_Release(punk); >+ return hres; >+} > >+/***************************************************************************** >+ * IInternetSecurityManager interface >+ */ >+cpp_quote("#define SID_SInternetSecurityManager IID_IInternetSecurityManager") >+ >+[ >+ object, >+ uuid(79eac9ee-baf9-11ce-8c82-00aa004ba90b), >+ pointer_default(unique) >+] >+interface IInternetSecurityManager : IUnknown >+{ >+ HRESULT SetSecuritySite( >+ [in, unique] IInternetSecurityMgrSite *pSite); >+ >+ HRESULT GetSecuritySite( >+ [out] IInternetSecurityMgrSite **ppSite); >+ >+ HRESULT MapUrlToZone( >+ [in] LPCWSTR pwszUrl, >+ [out] DWORD *pdwZone, >+ [in] DWORD dwFlags); >+ >+cpp_quote("#define MAX_SIZE_SECURITY_ID 512") > It is probably better to put this outside the interface declaration as I'm not sure if midl and widl are consistent about not outputting this twice. >+HRESULT SecManagerImpl_Construct(IUnknown *pUnkOuter, LPVOID *ppobj) >+{ >+ SecManagerImpl *This; > >+ >+ TRACE("(%p,%p)\n",pUnkOuter,ppobj); >+ This = HeapAlloc(GetProcessHeap(), 0, sizeof(*This)); > > The convention with COM interfaces is to use the CoTaskMemAlloc / CoTaskMemFree memory management functions instead of the Heap ones (even though they are the same). This is just a slight nit-pick. >+ >+ /* Initialize the virtual function table. */ >+ This->lpvtbl1 = &VT_SecManagerImpl; >+ This->ref = 1; >+ >+ *ppobj = This; >+ return S_OK; >+} > Rob

2 1

Re: PATCH: imagelist: change ERR to TRACE
by Andreas Mohr 28 Sep '04

28 Sep '04

Hi, On Tue, Sep 28, 2004 at 06:44:16AM +0200, Michael Stefaniuc wrote: > Hello, > > License: LGPL, X11 > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > - native ImageList_Remove dosn't spit out an error message when > deleting an index out of range so don't do that either Probably true, but native ImageList_Remove doesn't have its whole Windows environment completely buggy either. ;-) IOW: this was perhaps meant for Wine code bug tracking purposes (AFAIK Wine uses imagelists a lot internally, e.g. shell code or so). While an ERR is too verbose, TRACE is ill-suited for that (a wrong index certainly is an anomaly); thus I'd say it should be a WARN. Greetings, Andreas Mohr

2 1

Re: MakeSureDirectoryPathExists improvement
by Alexandre Julliard 28 Sep '04

28 Sep '04

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > @@ -91,13 +91,28 @@ > */ > BOOL WINAPI MakeSureDirectoryPathExists(LPCSTR DirPath) > { > - if (CreateDirectoryA(DirPath, NULL)) return TRUE; > - if (GetLastError() == ERROR_ALREADY_EXISTS) > + char path[MAX_PATH]; > + const char *p = DirPath; > + int n; > + > + if (strchr(p, ':') != NULL) > + p = strchr(p, ':'); > + while ((p = strchr(p, '\\')) != NULL) > { > - SetLastError(ERROR_SUCCESS); > - return TRUE; > + n = p - DirPath + 1; > + strncpy(path, DirPath, n); > + path[n] = '\0'; > + if( !CreateDirectoryA(path, NULL) && > + (GetLastError() != ERROR_ACCESS_DENIED) && > + (GetLastError() != ERROR_ALREADY_EXISTS)) > + return FALSE; > + p++; > } > - return FALSE; > + if (GetLastError() == ERROR_ACCESS_DENIED || > + (GetLastError() == ERROR_ALREADY_EXISTS)) > + SetLastError(ERROR_SUCCESS); > + > + return TRUE; I don't think you want to simply ignore ERROR_ACCESS_DENIED. You should fix your algorithm to not try to create the drive root and then ignore only ERROR_ALREADY_EXISTS. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winecfg: Add Makefile rules to rebuild resource file when translations change
by Alexandre Julliard 28 Sep '04

28 Sep '04

Mike Hearn <mike(a)navi.cx> writes: > Add Makefile rules to rebuild resource file when translations change 'make depend' is a convenient way to do that, maybe you should give it a try ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: stub implementation SystemFunction036
by Filip Navara 28 Sep '04

28 Sep '04

James Hawkins wrote: >+ >+VOID WINAPI SystemFunction036(PCHAR Buffer, INT BufferSize) >+{ >+ FIXME("(%s, %i): stub\n", Buffer, BufferSize); >+} >+ > > If you really want to stub this function then please don't print the buffer contents. It's an output buffer and contains garbage (maybe the garbage means something, but still it's garbage). - Filip

2 1

Re: SystemFunction036 debugging problem
by James Hawkins 27 Sep '04

27 Sep '04

> Is the target (the thing calling SystemFunction036) available to download > anywhere? Yea. here's the link: http://www.download.com/redir?pid=10287361&merid=107235&mfgid=107235&lop=li… On Tue, 28 Sep 2004 07:29:14 +0800, Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > Is the target (the thing calling SystemFunction036) available to download > anywhere? > > -- James Hawkins

1 0

Problems installing office 2k.
by James Pellow 27 Sep '04

27 Sep '04

Hi List, I just installed wine from cvs as of this morning and am still having problems installing office. I get the following error when starting the installer with the msi debugging channel on: fixme:msi:MsiEnableLogA 00000516 "c:\\windows\\temp\\Office 2000 Professional Setup (0014)_MsiExec.txt" 00000000 trace:msi:MsiEnableLogW 00000516 L"c:\\windows\\temp\\Office 2000 Professional Setup (0014)_MsiExec.txt" 00000000 trace:msi:MsiInstallProductA "/I" "" fixme:msi:MsiInstallProductW L"/I" L"" trace:msi:MsiVerifyPackageW L"/I" trace:msi:MsiOpenDatabaseW L"/I" (null) 0x4055fd78 trace:msi:MSI_OpenDatabaseW L"/I" (null) fixme:msi:MSI_OpenDatabaseW open failed r = 80004005! trace:msi:MsiCloseHandle 405aa5aa Installation of /I () failed. Mike had suggested I not use the builtin msi.dll. Since no native msi system was installed, the office 2k installer to tried to install one resulting in the following error: fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to (nil) fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to 0x50 err:ntdll:NtQueryInformationToken Unhandled Token Information class 8! fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to 0x44 fixme:powermgnt:SetThreadExecutionState (0x80000001): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x80000000): stub, harmless. fixme:thread:NtSetInformationThread Set ThreadImpersonationToken handle to (nil) Installation of /i (REBOOT=REALLYSUPRESS) failed. It is suprising to me that nobody else has reported this office 2k msi problem. I guess everyone is using OpenOffice these days :) I really don't use wine much, but I have been following its progress over the years and compile and test it once in a while. I am happy to do a little more debugging if someone wanted to give me some pointers. Thanks. Cheers, James -- ***************************** James A. Pellow, President Alent Design Solutions www.alentdesignsolutions.com (509) 526-0682 *****************************

1 0

edonkey2000 dll err
by J. Grant 27 Sep '04

27 Sep '04

Hello, As this is an "err, I thought I should post the the devl list. I am using CVS build from 2004-09-20. I am using DLL's copied from working win2k install. It seems quite fatal, any ideas? Kind regards JG c:\opt\ed2k>edonkey2000.exe c:\opt\ed2k>err:module:import_dll No implementation for MSVCRT.dll.??_U@YAPAXI@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef err:module:import_dll No implementation for MSVCRT.dll.??_V@YAXPAX@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef -- Homepage: http://jguk.org/ Blog: http://jguk.org/index.html#blog Radio: http://jguk.org/index.html#radio

3 3

Re: Getting winebuild to work on HP-UX
by Warren_Baird/CSI＠cimmetry.com 27 Sep '04

27 Sep '04

"Eric Frias" <efrias(a)syncad.com> wrote on 09/27/2004 09:52:12 AM: > I don't know if this made it through on Thursday; if not, here's a repeat: I saw it on the archive - sorry I didn't get a chance to respond on Friday. Thanks for the repeat, though - it saves me cutting and pasting from the browser. :-) > I'm afraid I won't be a lot of help right now, but I might be able to offer > some moral support. Well - at this point even moral support would be a good thing... > I've spent several weeks last year trying to get > winelib working on HPUX, but I don't really have anything to show for it. > Before I could get anything working, I had to abandon HPUX and work on > fixing up Linux and Solaris stuff because it was in higher demand. I'll > eventually need to get HPUX working also, but I won't be able to devote too > much time to it for at least a month. My timeline is probably tighter than that - I'm hoping to have winelib working within the next month... So you might be lucky. :-) > I was in the same situation as you are... very rusty at x86 assembly, able > to comprehend a little sparc assembly, but I didn't know a thing about > pa-risc. I was simply typing make, letting it run until it had some error > because HPUX wasn't supported, coming up with some fix for it, and > repeating. Some days I felt like I almost grasped what was going on and how > to fix it, and some days it felt like it was miles away. I never got all of > wine compiling, so I have no idea if any of the fixes I made were correct or > not. I'd be happy to share them with you, but seeing them might do you more > harm than good. Yeah, if you wouldn't mind, send me the patches --- It may give me some useful ideas, at least. > Anyway, good luck, and if you weren't looking for an excuse to learn pa-risc > assembly, well, you have my sympathies. I'm told it builds character :-) :-) then I guess my character is in for a bit of a work-out. <sigh> Thanks, Warren -- Warren Baird, Technical Group Leader warren_baird(a)cimmetry.com Cimmetry System Inc. 514 735 3219 x148

1 0

Wine User Guide changes (RFC)
by Brian Vincent 27 Sep '04

27 Sep '04

With Mike's recent Winecfg patches and the renewed hope we'll cut over to using Winecfg some day, I went through and began updating the Wine User Guide. The focus of the changes thus far was to remove references to the config file and discuss Winecfg instead. Without actually being able to use Winecfg these changes are useless, but it's probably worth looking this over to see whether these docs are headed in the right direction. For now, the biggest changes can be found in configuring.sgml (which translates into the "Configuring Wine" part of the guide.) A diff is available here: http://www.theshell.com/~vinn/wine-user-guide.diff However, this stuff is best looked at as a side-by-side comparison with the existing docs. You can find that here: http://www.theshell.com/~vinn/wine-user-guide.html (Not having looked at Mike's recent patches, I'm sure this will soon be out of date. Things like drive detection are missing. There's also parts that I left undone: such as the printing config, an appendix listing reg keys would be nice once we know what they all are. Other parts probably need a better explanation, such as font configuration. Anything you notice missing is probably worth telling me about, though it won't be hard to find lots of mistakes.) One of the big goals of all this is to reduce the amount of documentation and outdated stuff. Therefore, registry.sgml, printing.sgml, and fonts.sgml have been somewhat merged into configuring.sgml. fonts.sgml contained a lot of outdated info in it that probably caused more confusion than helped. Going forward, we have a lot of documentation in the User Guide about downloading Wine, compiling Wine, CVS, etc; mostly stuff that's already duplicated in some form or another on the web site. I'd like to see as much stuff like that removed from the User Guide as possible, we can simply refer people to WineHQ for more info. (I think the reason for the duplication is that the website docs simply didn't exist when the User Guide was written, now the website has superceded the User Guide.) When it's all said and done we should be left with the following sections: - Introduction - Configuration - Running - Troubleshooting At least, that's the direction I think it should go and at some point I could begin making those changes. Anyone disagree? Any thoughts, comments, concerns, criticisms? -Brian

2 1

tree/list-view slowness
by James Hawkins 27 Sep '04

27 Sep '04

I am currently working on making Kazaa Lite 2.4.3 more usable. The most major problem remaining is that when the user chooses to search for a file on the network, the program slows almost to a halt and becomes mostly unmanageable. The results are displayed in a tree/list-view in the right pane [1]. I've looked into both of the controls, and it seems like the slowness could be coming from their implementation, but even when I set comctl32 to native, the problem remains. Also, I've done a trace+treeview and a trace+listview and only treeview api's seem to be called and not listview. Would it be a possibility that they implemented their own listview? Can anyone describe a method I can use to track down the inefficiency? Thankyou for your help. [1] http://www.andrew.cmu.edu/user/jhawkins/klite.jpeg -- James Hawkins

2 1

Re: Listbox fixes
by Alexandre Julliard 27 Sep '04

27 Sep '04

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +dlls/user/listbox.c > Draw background of the empty selected item in empty lists > Dont draw a focus rect if we do not have the focus > Dont select items on key up/down in multi-select lists This is causing a test failure: listbox.c:134: Test failed: style 0x8, step step, field selected: expected 2, got 1 listbox.c:134: Test succeeded inside todo block: style 0x8, step step, field selcount: expected 1, got 1 (the second one is a good thing of course...) -- Alexandre Julliard julliard(a)winehq.org

5 6

slovenian keyboard support
by Rok 26 Sep '04

26 Sep '04

I'm using slackware 10, KDE and Wine 20040914 (binary) and have problems using specific letters: ---cut-here--- err:keyboard:X11DRV_ToUniCodeEx Please report: no char for keysym 01E8 (ccaron) : err:keyboard:X11DRV_ToUniCodeEx (virtKey=E2,scanCode=62,keycode=2F,state=10) err:keyboard:X11DRV_ToUniCodeEx Please report: no char for keysym 01C8 (Ccaron) : err:keyboard:X11DRV_ToUniCodeEx (virtKey=E2,scanCode=62,keycode=2F,state=11) err:keyboard:X11DRV_ToUniCodeEx Please report: no char for keysym 01B9 (scaron) : err:keyboard:X11DRV_ToUniCodeEx (virtKey=E0,scanCode=60,keycode=22,state=10) ... ---cut-here--- I'd need letters [cCsSzZ]caron [cC]acute [dD]stroke. Is there any this can be resolved? Thanks! LP,Rok.

2 1

(no subject)
by Arda Ataerkil 26 Sep '04

26 Sep '04

hi. i m new user Linux redhat. jop is Graphic Desgner. i want to shot Win Xp enought for virus and all bad thinks. but i need to use photoshop, flash, and other soft working with Windows. and i learned yesterday "wine" is makeing work with linux this software. is it true. i try to download it . but couldent find anywhere. could you give mea link . where ami download it. At your site too much packages . could you give to me a link all packages at 1 download file. couse i m newer user to diffucult do set up and download it for me at now. Regards.

2 1

Re: wine/loader preloader.c
by Mike Hearn 26 Sep '04

26 Sep '04

Hi Alexandre! What's the reasoning for this change? I thought the preloader should not be built as a PIE because otherwise the kernel could map it into one of the areas we need to reserve. More to the point, the people trying to do this are thinking it will increase security. It won't, even though this code is loaded at a known offset it does not contain any code you could exploit in a return-to-libc type attack and anyway, exploits through Wine are far more likely to come in through the software being run on it than Wine itself. There is a patch in bugzilla (I guess you saw this) to ensure -fno-pie and -fno-stack-protector is passed to gcc for the preloader. thanks -mike > Log message: > Support compiling with -fPIC for people who somehow think this is a > good idea.

4 3

Missing dll's and wine says it is going into debugger
by J. Grant 25 Sep '04

25 Sep '04

Hello, I have installed eDonkey2000, the free version from www.overnet.com. I am using a one day old CVS build of WINE. Could there be a Debug/Retry option for dll loading? then I would have time to copy the dlls and press Retry. As it is, I have to restart the entire process for each dll missing. fixme:win:SetWindowTextA cannot set text "Output folder: C:\\opt\\ed2k" of other process window 0x2006a fixme:win:SetWindowTextA cannot set text "Execute: C:\\opt\\ed2k\\eDonkey2000.exe" of other process window 0x2006a wine: Unhandled exception (thread 000b), starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x401c88e8 err:module:import_dll Library MSVCP60.dll (which is needed by L"C:\\opt\\ed2k\\edonkey2000.exe") not found err:module:import_dll Library MSVCIRT.dll (which is needed by L"C:\\opt\\ed2k\\edonkey2000.exe") not found Usage: winedbg [--auto] [--gdb] cmdline err:module:LdrInitializeThunk Main exe initialization for L"C:\\opt\\ed2k\\edonkey2000.exe" failed, status c0000135 These are the two dlls which were displayed on my terminal. It did not end up in the debugger though, just the terminal after I pressed ESC <Enter>. After I copied these dlls, and restarted the process I get this text: c:\opt\ed2k>edonkey2000.exe c:\opt\ed2k>err:module:import_dll No implementation for MSVCRT.dll.??_U@YAPAXI@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef err:module:import_dll No implementation for MSVCRT.dll.??_V@YAXPAX@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef although it is an "err" the process continues to run... would you like me to try and probe this dll futher to get the missing impelementation name it is complaining about? (if that would help) I am not on this list, so please include my email address in replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/index.html#blog Radio: http://jguk.org/index.html#radio

5 6

RE: Help with GetConsoleWindow()
by Ewert, Mark 25 Sep '04

25 Sep '04

Here's a more detailed dump: WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x41a41754 in 32-bit code (0x10007239). In 32 bit mode. 000f:err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 53445352 in module xdb Register dump: CS:0023 SS:002b DS:002b ES:002b FS:121f GS:002f EIP:10007239 ESP:44b5008c EBP:44b500ac EFLAGS:00010206( - 00 - RIP1) EAX:412e01e0 EBX:412e0098 ECX:0064ffcc EDX:413f178c ESI:0000003f EDI:413f200c Stack dump: 0x44b5008c: 00000000 00000090 0000008c 00000000 0x44b5009c: 000000a0 412e0324 0064ffcc 00000000 0x44b500ac: 44b500e4 10008f98 412e0098 00000000 0x44b500bc: 00000002 4020521c 0000008c 00000000 0x44b500cc: 44b500b8 44b4fc70 44b50124 100072dc 0x44b500dc: 10012060 00000000 44b500f8 10004c39 0243: sel=121f base=405ab000 limit=00001fff 32-bit rw- Backtrace: =>1 0x10007239 (0x44b500ac) 2 0x10008f98 (0x44b500e4) 3 0x10004c39 (0x44b500f8) 4 0x10004ce6 EntryPoint+0x5d in xdb (0x44b50134) 5 0x401d3c66 call_dll_entry_point+0x12 in ntdll (0x44b5014c) 6 0x401d4c61 MODULE_InitDLL+0x121(wm=0x403b9830, reason=0x2, lpReserved=0x0) [/home/wine-20040914/dlls/ntdll/loader.c:741] in ntdll (0x44b501b8) 7 0x401d4f47 MODULE_DllThreadAttach+0x77(lpReserved=0x0) [/home/wine-20040914/dlls/ntdll/loader.c:894] in ntdll (0x44b501e0) 8 0x4053aea3 THREAD_Start+0x73(ptr=0x403f8df8) [/home/wine-20040914/dlls/kernel/thread.c:107] in kernel32 (0x44b502a8) 9 0x401e956b start_thread+0x14b(info=0x403f8420) [/home/wine-20040914/dlls/ntdll/thread.c:199] in ntdll (0x44b50ae4) 10 0x40048c3f pthread_start_thread+0x16f(arg=0x44b50be0) [/usr/src/build/230306-i686/BUILD/glibc-2.2.4/linuxthreads/manager.c:287] in libpthread.so.0 (0x44b50bd4) 11 0x40144b2a000f:fixme:dbghelp_symt:symt_set_udt_size Changing size for _IO_FILE from 148 to 76 __clone+0x3a in libc.so.6 (0x00000000) 0x10007239: movl %ecx,0xfffffffc(%ecx,%edx,1) -----Original Message----- From: Eric Pouech [mailto:pouech-eric@wanadoo.fr] Sent: Thursday, September 23, 2004 12:23 PM To: Ewert, Mark Cc: Saulius Krasuckas; wine-devel(a)winehq.org Subject: Re: Help with GetConsoleWindow() Ewert, Mark a écrit : > This is the trace just before the exception that is seen: > > 0017:trace:loaddll:load_dll Loaded module > L"c:\\windows\\system\\ws2_32.dll" : builtin > 0017:trace:loaddll:load_dll Loaded module > L"Z:\\home\\xscale_xactor\\sandbox\\MSVCR71.dll" : native > 0017:trace:loaddll:load_dll Loaded module > L"Z:\\home\\xscale_xactor\\sandbox\\MSVCP71.dll" : native > 0017:trace:loaddll:load_dll Loaded module > L"Z:\\home\\xscale_xactor\\sandbox\\CoSimClient.dll" : native > 0017:trace:loaddll:load_dll Loaded module > L"Z:\\home\\xscale_xactor\\sandbox\\plugin\\xscale\\ixpirqgui\\irqgui.dl > l" : native > wine: Unhandled exception (thread 001a), starting debugger... > > Is the problem in irqgui.dll maybe, but you cannot tell what does the stack backtrace give ? A+

2 1

Vincent Beron:"Re:dividsion by zero in winword"
by Robbert Xerox 25 Sep '04

25 Sep '04

> So maybe we should actually check for the FAT signature at buff[0x36] or > buff[0x52] first, and then do the calculations if we actually do find > one of them. > > Changelog: > Make sure we're really looking at a FAT before doing some calculations > based on the contents of the first sector of a partition. That doesn't solve the real issue, a FAT signature is not a guarantee that the rest of the block is valid, so we still need to check these values against zero. The code should not crash no matter what garbage the block contains. -- Alexandre Julliard Well, Vincent's Beron patch solves at least my problem, i.e. the error is gone and the programs work fine now.thx Robbert ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

Error popop text not on terminal
by J. Grant 24 Sep '04

24 Sep '04

Hello, I am using eDonkey2000, installed on my CVS build. I installed with my config set to "win98", however I get the error in the attached popup when trying to run. I changed my config to "win2k" and I still have the problems, so I do not think that made any difference. Could the attached screenshot error text be displayed on the terminal with the other useful info please? (I normally see missing DLLs listed on the terminal, and occasionally also as a dialog. This error was only on a popup.) it is really hard to read the text on the popups, and I cannot copy paste into emails like this. If this popup could have only come from the program, I wonder if there is any way to log the program gui text from this msg box on the terminal? You can download the installer exe from this url if you would like to try yourself: http://www.overnet.com/downloads.php (the installer downloads and installs the program it seems) Over the course of several runs (restart of the process required for each missing dll), several popups I copied from my win2k install to get it working: kernel32.dll ntdll.dll user32.dll advapi32.dll rpcrt4.dll shell32.dll imm32.dll wsock32.dll ws2_32.dll ws2help.dll oleaut32.dll Into c:\windows\system as requested by the popups. On my win2k install these were in the "system32" dir. I wonder why is it hunting for them in "system" ? It does run though, see log attached. The screenshot shows the corrupted title bar, which cannot be moved. Any ideas how to solve this corruption problem? Also, perhaps there is a way to simplify the install of programs such as this which require so many dlls? Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/index.html#blog Radio: http://jguk.org/index.html#radio Please use the registry key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file fixme:font:WineEngCreateFontInstance just using first face for now WCMD Version 0.17 D:\>c:\>File not found c:\>c:\opt>c:\opt\ed2k>Volume in drive c is Volume Serial Number is 0000-0000 Directory of c:\opt\ed2k\ 20/09/2004 01:19 <DIR> . 20/09/2004 00:32 <DIR> .. 20/09/2004 01:15 418 5.html 20/09/2004 01:15 400 74.html 20/09/2004 00:32 11,504 contact.dat 20/09/2004 00:32 260 def.html 20/09/2004 01:19 <DIR> dis-plugins 20/09/2004 00:32 2,009,248 edonkey2000.exe 20/09/2004 01:19 0 filters.txt 20/09/2004 01:19 5 friend.met 20/09/2004 01:19 5 friend.met.bak 20/09/2004 01:19 5 known.met 20/09/2004 01:19 5 known.met.bak 20/09/2004 01:15 53 log.txt 20/09/2004 00:32 511 media.xml 07/12/1999 13:00 77,878 msvcirt.dll 29/08/2000 04:19 401,462 MSVCP60.DLL 20/09/2004 01:19 <DIR> Plugins 20/09/2004 01:19 1,233 pref.xml 20/09/2004 00:32 4,152 reg.jpg 20/09/2004 01:19 4,087 server.met 20/09/2004 01:19 4,087 server.met.bak 20/09/2004 01:19 39 share.dat 20/09/2004 01:19 39 share.dat.bak 20/09/2004 00:32 <DIR> Skins 20/09/2004 00:32 <DIR> temp 20/09/2004 00:32 37,125 uninstall_eDonkey2000.exe 21 files 2,552,516 bytes 6 directories 3,674,771,456 bytes free c:\opt\ed2k>c:\opt\ed2k>err:module:import_dll No implementation for MSVCRT.dll.??_U@YAPAXI@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef err:module:import_dll No implementation for MSVCRT.dll.??_V@YAXPAX@Z imported from L"C:\\opt\\ed2k\\MSVCIRT.dll", setting to 0xdeadbeef Please use the registry key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file fixme:font:WineEngCreateFontInstance just using first face for now fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 fixme:imm:ImmGetContext (0x10020): stub fixme:imm:ImmReleaseContext (0x10020, 0x40336368): stub ixme:imm:ImmReleaseContext (0x10020, 0x40336368): stub fixme:imm:ImmGetContext (0x501ca): stub fixme:imm:ImmReleaseContext (0x501ca, 0x40336360): stub fixme:imm:ImmGetContext (0x501ca): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x501ca, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406bda74): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406be104): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x5007a): stub fixme:imm:ImmReleaseContext (0x5007a, 0x40336360): stub fixme:imm:ImmGetContext (0x5007a): stub fixme:imm:ImmReleaseContext (0x5007a, 0x40336360): stub fixme:imm:ImmGetContext (0x5007a): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x5007a, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406bde84): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406be0e8): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406be0e8): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406be0e4): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406be0e4): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406be0e4): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x70254): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70254, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:system:SystemParametersInfoW Unimplemented action: 4100 (SPI_GETCOMBOBOXANIMATION) fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x6025e): stub fixme:imm:ImmReleaseContext (0x6025e, 0x40336360): stub fixme:imm:ImmGetContext (0x6025e): stub fixme:imm:ImmReleaseContext (0x6025e, 0x40336360): stub fixme:imm:ImmGetContext (0x6025e): stub fixme:imm:ImmReleaseContext (0x6025e, 0x40336360): stub fixme:imm:ImmGetContext (0x6025e): stub fixme:imm:ImmReleaseContext (0x6025e, 0x40336360): stub fixme:imm:ImmGetContext (0x6025e): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x6025e, 0x40336360): stub fixme:imm:ImmGetContext (0x6025e): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x6025e, 0x40336360): stub fixme:imm:ImmGetContext (0x6025e): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x6025e, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x702ae): stub fixme:imm:ImmReleaseContext (0x702ae, 0x40336360): stub fixme:imm:ImmGetContext (0x80254): stub fixme:imm:ImmReleaseContext (0x80254, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x50264): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50264, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406bdb8c): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub QPixmap::fromMimeSource: Cannot find pixmap "C:\opt\ed2k\skins\default\x-dis.png" in the mime source factory fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406be060): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmSetCompositionWindow STUB fixme:imm:ImmSetCandidateWindow (0x40336360, 0x406bdb20): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x70250): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x70250, 0x40336360): stub fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x502e6): stub fixme:imm:ImmReleaseContext (0x502e6, 0x40336360): stub fixme:system:SystemParametersInfoW Unimplemented action: 4098 (SPI_GETMENUANIMATION) fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:system:SystemParametersInfoW Unimplemented action: 4098 (SPI_GETMENUANIMATION) fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x50238): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50238, 0x40336360): stub fixme:imm:ImmGetContext (0x50228): stub fixme:imm:ImmReleaseContext (0x50228, 0x40336360): stub fixme:imm:ImmGetContext (0x50228): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50228, 0x40336360): stub fixme:imm:ImmGetContext (0x50228): stub fixme:imm:ImmReleaseContext (0x50228, 0x40336360): stub fixme:imm:ImmGetContext (0x50228): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50228, 0x40336360): stub fixme:imm:ImmGetContext (0x50228): stub fixme:imm:ImmReleaseContext (0x50228, 0x40336360): stub fixme:imm:ImmGetContext (0x50228): stub fixme:imm:ImmNotifyIME (0x40336360, 21, 4, 0): stub fixme:imm:ImmReleaseContext (0x50228, 0x40336360): stub fixme:imm:ImmGetContext (0x802c8): stub fixme:imm:ImmReleaseContext (0x802c8, 0x40336360): stub fixme:imm:ImmGetContext (0x502c2): stub fixme:imm:ImmReleaseContext (0x502c2, 0x40336360): stub

1 0

Re: Getting winebuild to work on HP-UX
by Warren_Baird/CSI＠cimmetry.com 24 Sep '04

24 Sep '04

(BTW, apologies for the Firewall/CSI thing in my previous message's "From:" line - they've been mucking about with our external mail server, and it messed something up - Hope people didn't get bounces if they tried replying directly - hopefully it'll be fixed for this message.) Alexandre Julliard wrote: > No, pretty much everything that can be done in C already is, the rest > really needs to be in assembly. It's a perfect opportunity to learn > PA-RISC assembly <g> I was afraid you'd say that -- 'cause I know as soon as I'm done the HP-UX port, I'm going to be asked to do an AIX port. Oh well - maybe I can piggyback off some of the MacOS stuff... I don't suppose there's any documentation around anywhere talking about exactly what the assembly code in winebuild is trying to accomplish, and why it can't be done in C? I'm afraid that my assembly is rough enough that I haven't been able to figure out what all of the import/export set up code is trying to do. Taking a description of what it's supposed to do, and then learning enough pa-risc assembly to do it will certainly be faster than reverse-engineering the assembly that's there and then trying to implement it for the pa-risc. Here's a brief summary of where I am: after making a few changes to various Makefile.in files to fix places where .so was used instead of $(LIBEXT), and fixing winegcc so that .so wasn't hardcoded in it either (patches will be forthcoming this aft), I'm at the point where the vast majority of the .c files compile (about 1470 - my linux build has 1596 .o files in it) - but nothing outside of libs/loader links, because of winebuild... So my next goal is really to get winebuild working... I guess I'll be cracking the pa-risc assembly language manual open soon... :-) Warren

2 1

Re: Get AdjustWindowRect working better
by Alexandre Julliard 24 Sep '04

24 Sep '04

Richard Cohen <richard(a)daijobu.co.uk> writes: > We shouldn't create a new file for *every single* test, but we should > do so for an unrelated test. How 'unmanageable' is adding 1 line to > Makefile.in? There are more than 700 APIs in user32 alone. If we create a new file for each one, that means 700 source files. Plus, with all the debug symbols, the smallest object file weighs in at least 100K, so that's a minimum of 70Mb of object files in that single directory. Multiply that by the 150 dlls we have and it should be obvious why it's unmanageable. > I would rather have the tests as *maintaineable*. If a test fails, > isn't it easier to look through 200 lines than 2000 lines ? No, since you get a line number with the failure message, you don't have to look through the whole file. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: Register Component Categories Manager
by Robert Shearman 24 Sep '04

24 Sep '04

Robert Shearman wrote: > Changelog: > Register component categories manager. Sorry, this patch is wrong. It seems it is already registered by comcat.dll, but some versions of the native ole32 seem to include the component categories manager. Rob

1 0

Re: Accept WM_SYSCHAR message for processsing in TranslateAcceleratorW
by Rein Klazes 24 Sep '04

24 Sep '04

On Thu, 16 Sep 2004 19:54:57 +0900, you wrote: > Hello, > Hi Dmitry, This patch is causing a regression in Agent (still existing in current CVS). If I use <alt>+W to access the Windows menu the program reacts as if I pressed just the 'W'. This is also an accelator key causing the current thread to be 'Watched'. Same thing with <ALT>+H, it should bring up the help menu. Now it causes the headers to display, normally behind the 'H' key. <ALT>-E works normal, probably because the 'E' is not accelerated. > this patch makes accelerator keys in my test MDI app (compiled with MSVC) > work under Wine. The problem is that Wine correctly generates WM_SYSKEY* > and WM_SYSCHAR messages when there is no focus window, but WM_SYSCHAR > is not considered by TranslateAcceleratorW as a valid input. Uhh, "The problem is that Wine correctly generates ...". Do you mean this is a hack? BTW. Your other patch "Make message flow for MDI ..." fixes the problem with maximized/restored MDI windows in Agent, thanks. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 8

Re: Support remote operations in wineserver
by Alexandre Julliard 24 Sep '04

24 Sep '04

"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes: > Hello > > I guess that original patch was too large. > I sent small pieces of it and they have been committed; however it seems that > this part cannot be downsized. Well, I'm not going to commit that part since it doesn't actually do anything with the remote operation, and it's not clear at all that the requests you added will be appropriate to whatever mechanism we use to do the remote operation. -- Alexandre Julliard julliard(a)winehq.org

4 5

Re: reading HEX and OCTAL numbers from input field
by James Hawkins 24 Sep '04

24 Sep '04

> Yes, I've put brown bag over my head Na, it's ok. You're new to the developemnt process of wine, and it can take a while to get a hang of the process. Just stick with it and things will be better in no time. On Thu, 23 Sep 2004 23:56:32 -0700, Primorec <igor.furlan(a)gmail.com> wrote: > Just forget my post.. I have not noticed that this feature was > already implemented. > > Yes, I've put brown bag over my head > > > > > On Thu, 23 Sep 2004 23:05:36 -0700, Primorec <igor.furlan(a)gmail.com> wrote: > > This patch allows user to enter HEX and/or OCTAL numbers into the form > > input field. > > > > This is my first patch and in the same time my second C program (first > > one was Hello World). > > So, please, have a mercy and be tolerant. > > > > Thanks > > > > Igor > > > > ? patch.diff > > Index: dlls/oleaut32/variant.c > > =================================================================== > > RCS file: /home/wine/wine/dlls/oleaut32/variant.c,v > > retrieving revision 1.102 > > diff -u -u -r1.102 variant.c > > --- dlls/oleaut32/variant.c 22 Sep 2004 19:12:18 -0000 1.102 > > +++ dlls/oleaut32/variant.c 24 Sep 2004 05:44:43 -0000 > > @@ -1556,6 +1556,8 @@ > > DWORD dwState = B_EXPONENT_START|B_INEXACT_ZEROS; > > int iMaxDigits = sizeof(rgbTmp) / sizeof(BYTE); > > int cchUsed = 0; > > + int value = 0; > > + OLECHAR first_element; > > > > TRACE("(%s,%ld,0x%08lx,%p,%p)\n", debugstr_w(lpszStr), lcid, > > dwFlags, pNumprs, rgbDig); > > > > @@ -1571,6 +1573,73 @@ > > pNumprs->nBaseShift = 0; > > pNumprs->nPwr10 = 0; > > > > + first_element = *lpszStr++; > > + > > + if ((first_element == '&') && (pNumprs->dwInFlags & NUMPRS_HEX_OCT)) > > + { > > + /* printf("TONY's hex string %s \n", debugstr_w(lpszStr)); */ > > + > > + first_element = *lpszStr++; > > + > > + if (first_element == 'h' || first_element == 'H') > > + { > > + pNumprs->nBaseShift = 4; /* hex number */ > > + first_element = *lpszStr++; > > + } > > + else > > + { > > + pNumprs->nBaseShift = 3; /* octal number */ > > + > > + if (first_element == 'o' || first_element == '0') > > + { > > + first_element = *lpszStr++; > > + } > > + } > > + > > + while (first_element == '0') > > + first_element = *lpszStr++; > > + > > + while (first_element != 0) > > + { > > + if (pNumprs->nBaseShift == 4) > > + { > > + if (first_element >= 'a' && first_element <= 'f') > > + value = first_element - 'a' + 10; /* making integer value > > out of hex character */ > > + else if (first_element >= 'A' && first_element <= 'F') > > + value = first_element - 'A' + 10; /* making integer value > > out of hex character */ > > + else if (first_element >= '0' && first_element <= '9') > > + value = first_element - '0'; > > + } > > + else > > + { > > + if (first_element >= '0' && first_element <= '7') > > + value = first_element - '0'; > > + } > > + rgbTmp[cchUsed] = value; > > + cchUsed++; /* count digits */ > > + first_element = *lpszStr++; > > + } > > + > > + if (cchUsed == 0) > > + { > > + value = 0; > > + rgbTmp[cchUsed] = value; > > + cchUsed = 1; > > + } > > + > > + pNumprs->cDig = cchUsed; > > + > > + memcpy(rgbDig, rgbTmp, pNumprs->cDig * sizeof(BYTE)); > > + return S_OK; > > + } > > + > > + if (!pNumprs || !rgbDig) > > + return E_INVALIDARG; > > + > > + if (pNumprs->cDig < iMaxDigits) > > + iMaxDigits = pNumprs->cDig; > > + > > + > > if (!lpszStr) > > return DISP_E_TYPEMISMATCH; > > > > @@ -1971,6 +2040,26 @@ > > > > if (pNumprs->nBaseShift) > > { > > + > > + /* we have to be sure that the number does not use more than 32 bits > > + * I am not sure if this is 100% valid - perhaps we should test for 64 ?? */ > > + int bitCount = (pNumprs->nBaseShift) * (pNumprs->cDig); > > + if (bitCount > 32) > > + return DISP_E_OVERFLOW; > > + > > + ULONG intValue = 0; > > + for ( ; pNumprs->cDig > 0; pNumprs->cDig--) > > + intValue = (intValue << (pNumprs->nBaseShift)) + *rgbDig++; > > + > > + FIXME("Only VTBIT_I2 implemented. Need to add other cases : > > VTBIT_I1, VTBIT_UI1 ... etc \n"); > > + if (dwVtBits & VTBIT_I2) > > + { > > + V_VT(pVarDst) = VT_I2; > > + V_I2(pVarDst) = intValue; > > + return S_OK; > > + } > > + > > + > > /* nBaseShift indicates a hex or octal number */ > > ULONG64 ul64 = 0; > > LONG64 l64; > > > > -- James Hawkins

1 0

Re: Contributing to WINE
by Dan Kegel 24 Sep '04

24 Sep '04

Alexandre Julliard wrote: > I got his mails and replied (even though they were sent as Word > documents which was a big pain to read). I imagine he never got the > replies, it seems your mail setup needs some work. Maybe you should fax your first reply to make sure he gets it. Specops fax # is, according to their web site, 632 532-5875. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: [dx9-2] Make d3d8 know about the wined3d device
by Alexandre Julliard 23 Sep '04

23 Sep '04

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > +/* No reference counting is required as there will be only one reference from > + Direct3DCreateX, and released when the reference count of that object gets to 0 */ > ULONG WINAPI IWineD3DImpl_AddRef(IWineD3D *iface) { > + IWineD3DImpl *This = (IWineD3DImpl *)iface; > + FIXME("(%p) : AddRef should never be called\n", This); > return 1; > } > > ULONG WINAPI IWineD3DImpl_Release(IWineD3D *iface) { > + IWineD3DImpl *This = (IWineD3DImpl *)iface; > + TRACE("(%p) : Releasing\n", This); > + HeapFree(GetProcessHeap(), 0, This); > return 0; > } If you are going to free the object on Release() then you should really do proper ref counting. It costs basically nothing and it will avoid a lot of headaches. Dummy refcounting is OK only if the count really doesn't matter, i.e. the object never gets released. -- Alexandre Julliard julliard(a)winehq.org

1 0

Janitorial Projects > COM objects
by Joris Huizer 23 Sep '04

23 Sep '04

Hello, Just to get started, I thought I could do some work of the Interlocking cleanup; The first patch wasn't applied yet so it's included in this patch as well I tried to do as suggested in the patch on the site and came up with this; I hope it's usefull... regards, Joris Index: dlls/ole32/antimoniker.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/antimoniker.c,v retrieving revision 1.21 diff -u -r1.21 antimoniker.c --- dlls/ole32/antimoniker.c 9 Sep 2004 21:03:58 -0000 1.21 +++ dlls/ole32/antimoniker.c 23 Sep 2004 20:35:17 -0000 @@ -186,7 +186,7 @@ TRACE("(%p)\n",This); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -195,19 +195,21 @@ ULONG WINAPI AntiMonikerImpl_Release(IMoniker* iface) { AntiMonikerImpl *This = (AntiMonikerImpl *)iface; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; + ref = InterlockedDecrement(&This->ref); + /* destroy the object if there's no more reference on it */ - if (This->ref==0){ + if (ref == 0){ AntiMonikerImpl_Destroy(This); return 0; } - return This->ref; + return ref; } /****************************************************************************** Index: dlls/ole32/bindctx.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/bindctx.c,v retrieving revision 1.28 diff -u -r1.28 bindctx.c --- dlls/ole32/bindctx.c 9 Sep 2004 21:03:58 -0000 1.28 +++ dlls/ole32/bindctx.c 23 Sep 2004 20:35:17 -0000 @@ -142,7 +142,7 @@ TRACE("(%p)\n",This); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -151,12 +151,13 @@ ULONG WINAPI BindCtxImpl_Release(IBindCtx* iface) { BindCtxImpl *This = (BindCtxImpl *)iface; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; + ref = InterlockedDecrement(&This->ref); - if (This->ref==0){ + if (ref == 0){ /* release all registered objects */ BindCtxImpl_ReleaseBoundObjects((IBindCtx*)This); @@ -165,7 +166,7 @@ return 0; } - return This->ref; + return ref; } Index: dlls/ole32/clipboard.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/clipboard.c,v retrieving revision 1.34 diff -u -r1.34 clipboard.c --- dlls/ole32/clipboard.c 9 Sep 2004 21:03:58 -0000 1.34 +++ dlls/ole32/clipboard.c 23 Sep 2004 20:35:19 -0000 @@ -1162,9 +1162,8 @@ TRACE("(%p)->(count=%lu)\n",This, This->ref); - This->ref++; + return InterlockedIncrement(&This->ref); - return This->ref; } /************************************************************************ @@ -1179,23 +1178,24 @@ * Declare "This" pointer */ OLEClipbrd *This = (OLEClipbrd *)iface; + ULONG ref; TRACE("(%p)->(count=%lu)\n",This, This->ref); /* * Decrease the reference count on this object. */ - This->ref--; + ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (This->ref==0) + if (ref == 0) { OLEClipbrd_Destroy(This); } - return This->ref; + return ref; } @@ -1651,7 +1651,7 @@ if (This->pUnkDataObj) IUnknown_AddRef(This->pUnkDataObj); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /************************************************************************ @@ -1663,13 +1663,15 @@ { IEnumFORMATETCImpl *This = (IEnumFORMATETCImpl *)iface; LPMALLOC pIMalloc; + ULONG ref; TRACE("(%p)->(count=%lu)\n",This, This->ref); if (This->pUnkDataObj) IUnknown_Release(This->pUnkDataObj); /* Release parent data object */ - if (!--(This->ref)) + ref = InterlockedDecrement(&This->ref); + if (!ref) { TRACE("() - destroying IEnumFORMATETC(%p)\n",This); if (SUCCEEDED(CoGetMalloc(MEMCTX_TASK, &pIMalloc))) @@ -1682,7 +1684,7 @@ return 0; } - return This->ref; + return ref; } /************************************************************************ Index: dlls/ole32/compositemoniker.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compositemoniker.c,v retrieving revision 1.31 diff -u -r1.31 compositemoniker.c --- dlls/ole32/compositemoniker.c 9 Sep 2004 21:03:58 -0000 1.31 +++ dlls/ole32/compositemoniker.c 23 Sep 2004 20:35:20 -0000 @@ -243,7 +243,7 @@ TRACE("(%p)\n",This); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -253,13 +253,14 @@ { CompositeMonikerImpl *This = (CompositeMonikerImpl *)iface; ULONG i; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; + ref = InterlockedDecrement(&This->ref); /* destroy the object if there's no more reference on it */ - if (This->ref==0){ + if (ref == 0){ /* release all the components before destroying this object */ for (i=0;i<This->tabLastIndex;i++) @@ -269,7 +270,7 @@ return 0; } - return This->ref; + return ref; } /****************************************************************************** @@ -1527,7 +1528,7 @@ TRACE("(%p)\n",This); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } @@ -1537,14 +1538,14 @@ ULONG WINAPI EnumMonikerImpl_Release(IEnumMoniker* iface) { EnumMonikerImpl *This = (EnumMonikerImpl *)iface; - ULONG i - ; + ULONG i; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; + ref = InterlockedDecrement(&This->ref); /* destroy the object if there's no more reference on it */ - if (This->ref==0){ + if (ref == 0) { for(i=0;i<This->tabSize;i++) IMoniker_Release(This->tabMoniker[i]); @@ -1554,7 +1555,7 @@ return 0; } - return This->ref; + return ref; } /****************************************************************************** Index: dlls/ole32/datacache.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/datacache.c,v retrieving revision 1.26 diff -u -r1.26 datacache.c --- dlls/ole32/datacache.c 23 Aug 2004 19:39:50 -0000 1.26 +++ dlls/ole32/datacache.c 23 Sep 2004 20:35:21 -0000 @@ -968,10 +968,11 @@ IUnknown* iface) { _ICOM_THIS_From_NDIUnknown(DataCache, iface); + ULONG ref; - this->ref++; + ref = InterlockedIncrement(&this->ref); - return this->ref; + return ref; } /************************************************************************ @@ -986,23 +987,24 @@ IUnknown* iface) { _ICOM_THIS_From_NDIUnknown(DataCache, iface); + ULONG ref; /* * Decrease the reference count on this object. */ - this->ref--; + ref = InterlockedDecrement(&this->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (this->ref==0) + if (ref == 0) { DataCache_Destroy(this); return 0; } - return this->ref; + return ref; } /********************************************************* Index: dlls/ole32/defaulthandler.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/defaulthandler.c,v retrieving revision 1.19 diff -u -r1.19 defaulthandler.c --- dlls/ole32/defaulthandler.c 23 Aug 2004 19:39:50 -0000 1.19 +++ dlls/ole32/defaulthandler.c 23 Sep 2004 20:35:22 -0000 @@ -656,10 +656,11 @@ IUnknown* iface) { _ICOM_THIS_From_NDIUnknown(DefaultHandler, iface); + ULONG ref; - this->ref++; + ref = InterlockedIncrement(&this->ref); - return this->ref; + return ref; } /************************************************************************ @@ -674,23 +675,24 @@ IUnknown* iface) { _ICOM_THIS_From_NDIUnknown(DefaultHandler, iface); + ULONG ref; /* * Decrease the reference count on this object. */ - this->ref--; + ref = InterlockedDecrement(&this->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (this->ref==0) + if (ref == 0) { DefaultHandler_Destroy(this); return 0; } - return this->ref; + return ref; } /********************************************************* Index: dlls/ole32/filemoniker.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/filemoniker.c,v retrieving revision 1.38 diff -u -r1.38 filemoniker.c --- dlls/ole32/filemoniker.c 9 Sep 2004 21:03:58 -0000 1.38 +++ dlls/ole32/filemoniker.c 23 Sep 2004 20:35:23 -0000 @@ -194,7 +194,7 @@ TRACE("(%p)\n",iface); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -203,19 +203,20 @@ ULONG WINAPI FileMonikerImpl_Release(IMoniker* iface) { FileMonikerImpl *This = (FileMonikerImpl *)iface; + ULONG ref; TRACE("(%p)\n",iface); - This->ref--; + ref = InterlockedDecrement(&This->ref); /* destroy the object if there's no more reference on it */ - if (This->ref==0){ + if (ref == 0) { FileMonikerImpl_Destroy(This); return 0; } - return This->ref; + return ref; } /****************************************************************************** Index: dlls/ole32/hglobalstream.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/hglobalstream.c,v retrieving revision 1.25 diff -u -r1.25 hglobalstream.c --- dlls/ole32/hglobalstream.c 23 Aug 2004 19:39:50 -0000 1.25 +++ dlls/ole32/hglobalstream.c 23 Sep 2004 20:35:24 -0000 @@ -378,10 +378,11 @@ IStream* iface) { HGLOBALStreamImpl* const This=(HGLOBALStreamImpl*)iface; + ULONG ref; - This->ref++; + ref = InterlockedIncrement(&This->ref); - return This->ref; + return ref; } /*** @@ -392,12 +393,9 @@ IStream* iface) { HGLOBALStreamImpl* const This=(HGLOBALStreamImpl*)iface; - ULONG newRef; - This->ref--; - - newRef = This->ref; + newRef = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. Index: dlls/ole32/itemmoniker.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/itemmoniker.c,v retrieving revision 1.28 diff -u -r1.28 itemmoniker.c --- dlls/ole32/itemmoniker.c 9 Sep 2004 21:03:58 -0000 1.28 +++ dlls/ole32/itemmoniker.c 23 Sep 2004 20:35:25 -0000 @@ -193,7 +193,7 @@ TRACE("(%p)\n",This); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -202,19 +202,20 @@ ULONG WINAPI ItemMonikerImpl_Release(IMoniker* iface) { ItemMonikerImpl *This = (ItemMonikerImpl *)iface; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; + ref = InterlockedDecrement(&This->ref); /* destroy the object if there's no more reference on it */ - if (This->ref==0){ + if (ref == 0){ ItemMonikerImpl_Destroy(This); return 0; } - return This->ref; + return ref; } /****************************************************************************** Index: dlls/ole32/marshal.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/marshal.c,v retrieving revision 1.31 diff -u -r1.31 marshal.c --- dlls/ole32/marshal.c 9 Sep 2004 21:03:58 -0000 1.31 +++ dlls/ole32/marshal.c 23 Sep 2004 20:35:25 -0000 @@ -217,17 +217,20 @@ static ULONG WINAPI StdMarshalImpl_AddRef(LPMARSHAL iface) { StdMarshalImpl *This = (StdMarshalImpl *)iface; - This->ref++; - return This->ref; + ULONG ref; + ref = InterlockedIncrement(&This->ref); + return ref; } static ULONG WINAPI StdMarshalImpl_Release(LPMARSHAL iface) { StdMarshalImpl *This = (StdMarshalImpl *)iface; - This->ref--; + ULONG ref; + ref = InterlockedDecrement(&This->ref); - if (This->ref) - return This->ref; + /* why is this syntax so different ?? */ + if (ref) + return ref; HeapFree(GetProcessHeap(),0,This); return 0; } Index: dlls/ole32/memlockbytes.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/memlockbytes.c,v retrieving revision 1.20 diff -u -r1.20 memlockbytes.c --- dlls/ole32/memlockbytes.c 23 Aug 2004 19:39:50 -0000 1.20 +++ dlls/ole32/memlockbytes.c 23 Sep 2004 20:35:25 -0000 @@ -351,10 +351,11 @@ ULONG WINAPI HGLOBALLockBytesImpl_AddRef(ILockBytes* iface) { HGLOBALLockBytesImpl* const This=(HGLOBALLockBytesImpl*)iface; + ULONG ref; - This->ref++; + ref = InterlockedIncrement(&This->ref); - return This->ref; + return ref; } /****************************************************************************** @@ -365,21 +366,19 @@ { HGLOBALLockBytesImpl* const This=(HGLOBALLockBytesImpl*)iface; - ULONG newRef; + ULONG ref; - This->ref--; - - newRef = This->ref; + ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (newRef==0) + if (ref==0) { HGLOBALLockBytesImpl_Destroy(This); } - return newRef; + return ref; } /****************************************************************************** Index: dlls/ole32/memlockbytes16.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/memlockbytes16.c,v retrieving revision 1.8 diff -u -r1.8 memlockbytes16.c --- dlls/ole32/memlockbytes16.c 12 Aug 2004 23:00:55 -0000 1.8 +++ dlls/ole32/memlockbytes16.c 23 Sep 2004 20:35:26 -0000 @@ -277,12 +277,13 @@ ULONG WINAPI HGLOBALLockBytesImpl16_AddRef(ILockBytes16* iface) { HGLOBALLockBytesImpl16* const This=(HGLOBALLockBytesImpl16*)iface; + ULONG ref; TRACE("(%p)\n",This); - This->ref++; + ref = InterlockedIncrement(&This->ref); - return This->ref; + return ref; } /****************************************************************************** @@ -293,19 +294,17 @@ { HGLOBALLockBytesImpl16* const This=(HGLOBALLockBytesImpl16*)iface; - ULONG newRef; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; - - newRef = This->ref; + ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (newRef==0) + if (ref==0) HGLOBALLockBytesImpl16_Destroy(This); - return newRef; + return ref; } /****************************************************************************** Index: dlls/ole32/moniker.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/moniker.c,v retrieving revision 1.35 diff -u -r1.35 moniker.c --- dlls/ole32/moniker.c 9 Sep 2004 21:03:58 -0000 1.35 +++ dlls/ole32/moniker.c 23 Sep 2004 20:35:26 -0000 @@ -145,7 +145,7 @@ TRACE("(%p)\n",This); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /*********************************************************************** @@ -174,13 +174,14 @@ { DWORD i; RunningObjectTableImpl *This = (RunningObjectTableImpl *)iface; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; + ref = InterlockedDecrement(&This->ref); /* unitialize ROT structure if there's no more reference to it*/ - if (This->ref==0){ + if (ref == 0) { /* release all registered objects */ for(i=0;i<This->runObjTabLastIndx;i++) @@ -201,7 +202,7 @@ return 0; } - return This->ref; + return ref; } /*********************************************************************** Index: dlls/ole32/oleobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/oleobj.c,v retrieving revision 1.18 diff -u -r1.18 oleobj.c --- dlls/ole32/oleobj.c 9 Sep 2004 21:03:58 -0000 1.18 +++ dlls/ole32/oleobj.c 23 Sep 2004 20:35:27 -0000 @@ -189,17 +189,18 @@ LPOLEADVISEHOLDER iface) { OleAdviseHolderImpl *This = (OleAdviseHolderImpl *)iface; + ULONG ref; TRACE("(%p)->(ref=%ld)\n", This, This->ref); - This->ref--; + ref = InterlockedDecrement(&This->ref); - if (This->ref == 0) + if (ref == 0) { OleAdviseHolderImpl_Destructor(This); return 0; } - return This->ref; + return ref; } /****************************************************************************** @@ -523,10 +524,12 @@ IDataAdviseHolder* iface) { DataAdviseHolder *This = (DataAdviseHolder *)iface; + ULONG ref; + TRACE("(%p) (ref=%ld)\n", This, This->ref); - This->ref++; + ref = InterlockedIncrement(&This->ref); - return This->ref; + return ref; } /************************************************************************ @@ -538,24 +541,25 @@ IDataAdviseHolder* iface) { DataAdviseHolder *This = (DataAdviseHolder *)iface; + ULONG ref; TRACE("(%p) (ref=%ld)\n", This, This->ref); /* * Decrease the reference count on this object. */ - This->ref--; + ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (This->ref==0) + if (ref==0) { DataAdviseHolder_Destructor(This); return 0; } - return This->ref; + return ref; } /************************************************************************ Index: dlls/ole32/oleproxy.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/oleproxy.c,v retrieving revision 1.21 diff -u -r1.21 oleproxy.c --- dlls/ole32/oleproxy.c 9 Sep 2004 21:03:58 -0000 1.21 +++ dlls/ole32/oleproxy.c 23 Sep 2004 20:35:27 -0000 @@ -103,18 +103,20 @@ static ULONG WINAPI CFStub_AddRef(LPRPCSTUBBUFFER iface) { CFStub *This = (CFStub *)iface; + ULONG ref; - This->ref++; - return This->ref; + ref = InterlockedIncrement(&This->ref); + return ref; } static ULONG WINAPI CFStub_Release(LPRPCSTUBBUFFER iface) { CFStub *This = (CFStub *)iface; + ULONG ref; - This->ref--; - if (This->ref) - return This->ref; + ref = InterlockedDecrement(&This->ref); + if (ref) + return ref; HeapFree(GetProcessHeap(),0,This); return 0; } @@ -286,18 +288,19 @@ static ULONG WINAPI IRpcProxyBufferImpl_AddRef(LPRPCPROXYBUFFER iface) { ICOM_THIS_MULTI(CFProxy,lpvtbl_proxy,iface); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } static ULONG WINAPI IRpcProxyBufferImpl_Release(LPRPCPROXYBUFFER iface) { ICOM_THIS_MULTI(CFProxy,lpvtbl_proxy,iface); + ULONG ref = InterlockedDecrement(&This->ref); - if (!--(This->ref)) { + if (!ref) { IRpcChannelBuffer_Release(This->chanbuf);This->chanbuf = NULL; HeapFree(GetProcessHeap(),0,This); return 0; } - return This->ref; + return ref; } static HRESULT WINAPI IRpcProxyBufferImpl_Connect(LPRPCPROXYBUFFER iface,IRpcChannelBuffer* pRpcChannelBuffer) { @@ -330,16 +333,19 @@ } static ULONG WINAPI CFProxy_AddRef(LPCLASSFACTORY iface) { + ULONG ref; ICOM_THIS_MULTI(CFProxy,lpvtbl_cf,iface); - This->ref++; - return This->ref; + ref = InterlockedIncrement(&This->ref); + return ref; } static ULONG WINAPI CFProxy_Release(LPCLASSFACTORY iface) { + ULONG ref; ICOM_THIS_MULTI(CFProxy,lpvtbl_cf,iface); - This->ref--; - if (This->ref) - return This->ref; + + ref = InterlockedDecrement(&This->ref); + if (ref) + return ref; HeapFree(GetProcessHeap(),0,This); return 0; } Index: dlls/ole32/rpc.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/rpc.c,v retrieving revision 1.26 diff -u -r1.26 rpc.c --- dlls/ole32/rpc.c 9 Sep 2004 21:03:58 -0000 1.26 +++ dlls/ole32/rpc.c 23 Sep 2004 20:35:28 -0000 @@ -286,20 +286,22 @@ static ULONG WINAPI PipeBuf_AddRef(LPRPCCHANNELBUFFER iface) { PipeBuf *This = (PipeBuf *)iface; - This->ref++; - return This->ref; + ULONG ref; + ref = InterlockedIncrement(&This->ref); + return ref; } static ULONG WINAPI PipeBuf_Release(LPRPCCHANNELBUFFER iface) { PipeBuf *This = (PipeBuf *)iface; + ULONG ref; wine_rpc_disconnect_header header; HANDLE pipe; DWORD reqtype = REQTYPE_DISCONNECT; - This->ref--; - if (This->ref) - return This->ref; + ref = InterlockedDecrement(&This->ref); + if (ref) + return ref; FIXME("Free all stuff\n"); Index: dlls/ole32/stg_stream.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/stg_stream.c,v retrieving revision 1.21 diff -u -r1.21 stg_stream.c --- dlls/ole32/stg_stream.c 23 Aug 2004 19:39:50 -0000 1.21 +++ dlls/ole32/stg_stream.c 23 Sep 2004 20:35:28 -0000 @@ -222,9 +222,10 @@ { StgStreamImpl* const This=(StgStreamImpl*)iface; - This->ref++; + ULONG ref; + ref = InterlockedIncrement(&This->ref); - return This->ref; + return ref; } /*** @@ -236,21 +237,19 @@ { StgStreamImpl* const This=(StgStreamImpl*)iface; - ULONG newRef; + ULONG ref; - This->ref--; - - newRef = This->ref; + ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (newRef==0) + if (ref==0) { StgStreamImpl_Destroy(This); } - return newRef; + return ref; } /*** Index: dlls/ole32/storage.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/storage.c,v retrieving revision 1.42 diff -u -r1.42 storage.c --- dlls/ole32/storage.c 22 Sep 2004 02:46:40 -0000 1.42 +++ dlls/ole32/storage.c 23 Sep 2004 20:35:29 -0000 @@ -986,7 +986,7 @@ */ ULONG WINAPI IStream16_fnAddRef(IStream16* iface) { IStream16Impl *This = (IStream16Impl *)iface; - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -994,15 +994,16 @@ */ ULONG WINAPI IStream16_fnRelease(IStream16* iface) { IStream16Impl *This = (IStream16Impl *)iface; + ULONG ref; FlushFileBuffers(This->hf); - This->ref--; - if (!This->ref) { + ref = InterlockedDecrement(&This->ref); + if (!ref) { CloseHandle(This->hf); UnMapLS( This->thisptr ); HeapFree( GetProcessHeap(), 0, This ); return 0; } - return This->ref; + return ref; } /****************************************************************************** @@ -1480,7 +1481,7 @@ */ ULONG WINAPI IStream_fnAddRef(IStream* iface) { IStream32Impl *This = (IStream32Impl *)iface; - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -1488,14 +1489,15 @@ */ ULONG WINAPI IStream_fnRelease(IStream* iface) { IStream32Impl *This = (IStream32Impl *)iface; + ULONG ref; FlushFileBuffers(This->hf); - This->ref--; - if (!This->ref) { + ref = InterlockedDecrement(&This->ref); + if (!ref) { CloseHandle(This->hf); HeapFree( GetProcessHeap(), 0, This ); return 0; } - return This->ref; + return ref; } /* --- IStorage16 implementation */ @@ -1534,7 +1536,7 @@ */ ULONG WINAPI IStorage16_fnAddRef(IStorage16* iface) { IStorage16Impl *This = (IStorage16Impl *)iface; - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -1542,9 +1544,10 @@ */ ULONG WINAPI IStorage16_fnRelease(IStorage16* iface) { IStorage16Impl *This = (IStorage16Impl *)iface; - This->ref--; - if (This->ref) - return This->ref; + ULONG ref; + ref = InterlockedDecrement(&This->ref); + if (ref) + return ref; UnMapLS( This->thisptr ); HeapFree( GetProcessHeap(), 0, This ); return 0; Index: dlls/ole32/storage32.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/storage32.c,v retrieving revision 1.59 diff -u -r1.59 storage32.c --- dlls/ole32/storage32.c 22 Sep 2004 02:46:40 -0000 1.59 +++ dlls/ole32/storage32.c 23 Sep 2004 20:35:34 -0000 @@ -291,9 +291,9 @@ IStorage* iface) { StorageBaseImpl *This = (StorageBaseImpl *)iface; - This->ref++; + ULONG ref = InterlockedIncrement(&This->ref); - return This->ref; + return ref; } /************************************************************************ @@ -311,12 +311,12 @@ /* * Decrease the reference count on this object. */ - This->ref--; + ULONG ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (This->ref==0) + if (ref == 0) { /* * Since we are using a system of base-classes, we want to call the @@ -328,7 +328,7 @@ return 0; } - return This->ref; + return ref; } /************************************************************************ @@ -3638,8 +3638,8 @@ { IEnumSTATSTGImpl* const This=(IEnumSTATSTGImpl*)iface; - This->ref++; - return This->ref; + ULONG ref = InterlockedIncrement(&This->ref); + return ref; } ULONG WINAPI IEnumSTATSTGImpl_Release( @@ -3649,8 +3649,7 @@ ULONG newRef; - This->ref--; - newRef = This->ref; + newRef = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. Index: dlls/oleaut32/connpt.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/connpt.c,v retrieving revision 1.12 diff -u -r1.12 connpt.c --- dlls/oleaut32/connpt.c 9 Sep 2004 21:03:58 -0000 1.12 +++ dlls/oleaut32/connpt.c 23 Sep 2004 20:35:34 -0000 @@ -193,10 +193,11 @@ static ULONG WINAPI ConnectionPointImpl_AddRef(IConnectionPoint* iface) { ConnectionPointImpl *This = (ConnectionPointImpl *)iface; + ULONG ref; TRACE("(%p)->(ref=%ld)\n", This, This->ref); - This->ref++; + ref = InterlockedIncrement(&This->ref); - return This->ref; + return ref; } /************************************************************************ @@ -208,24 +209,25 @@ IConnectionPoint* iface) { ConnectionPointImpl *This = (ConnectionPointImpl *)iface; + ULONG ref; TRACE("(%p)->(ref=%ld)\n", This, This->ref); /* * Decrease the reference count on this object. */ - This->ref--; + ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (This->ref==0) + if (ref == 0) { ConnectionPointImpl_Destroy(This); return 0; } - return This->ref; + return ref; } /************************************************************************ @@ -473,10 +475,11 @@ static ULONG WINAPI EnumConnectionsImpl_AddRef(IEnumConnections* iface) { EnumConnectionsImpl *This = (EnumConnectionsImpl *)iface; + ULONG ref; TRACE("(%p)->(ref=%ld)\n", This, This->ref); - This->ref++; + ref = InterlockedIncrement(&This->ref); IUnknown_AddRef(This->pUnk); - return This->ref; + return ref; } /************************************************************************ @@ -487,6 +490,7 @@ static ULONG WINAPI EnumConnectionsImpl_Release(IEnumConnections* iface) { EnumConnectionsImpl *This = (EnumConnectionsImpl *)iface; + ULONG ref; TRACE("(%p)->(ref=%ld)\n", This, This->ref); IUnknown_Release(This->pUnk); @@ -494,19 +498,19 @@ /* * Decrease the reference count on this object. */ - This->ref--; + ref = InterlockedDecrement(&This->ref); /* * If the reference count goes down to 0, perform suicide. */ - if (This->ref==0) + if (ref == 0) { EnumConnectionsImpl_Destroy(This); return 0; } - return This->ref; + return ref; } /************************************************************************ Index: dlls/oleaut32/dispatch.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/dispatch.c,v retrieving revision 1.20 diff -u -r1.20 dispatch.c --- dlls/oleaut32/dispatch.c 9 Sep 2004 21:03:58 -0000 1.20 +++ dlls/oleaut32/dispatch.c 23 Sep 2004 20:35:35 -0000 @@ -278,7 +278,7 @@ StdDispatch *This = (StdDispatch *)iface; TRACE("()\n"); - return ++This->ref; + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -289,18 +289,18 @@ static ULONG WINAPI StdDispatch_Release(LPDISPATCH iface) { StdDispatch *This = (StdDispatch *)iface; - ULONG ret; + ULONG ref; TRACE("(%p)->()\n", This); - ret = This->ref--; + ref = InterlockedDecrement(&This->ref); - if (This->ref == 0) + if (ref == 0) { ITypeInfo_Release(This->pTypeInfo); CoTaskMemFree(This); } - return ret; + return ref; } /****************************************************************************** Index: dlls/urlmon/umon.c =================================================================== RCS file: /home/wine/wine/dlls/urlmon/umon.c,v retrieving revision 1.41 diff -u -r1.41 umon.c --- dlls/urlmon/umon.c 22 Sep 2004 02:46:39 -0000 1.41 +++ dlls/urlmon/umon.c 23 Sep 2004 20:35:36 -0000 @@ -197,7 +197,7 @@ TRACE("(%p)\n",This); - return ++(This->ref); + return InterlockedIncrement(&This->ref); } /****************************************************************************** @@ -206,19 +206,20 @@ static ULONG WINAPI URLMonikerImpl_Release(IMoniker* iface) { URLMonikerImpl *This = (URLMonikerImpl *)iface; + ULONG ref; TRACE("(%p)\n",This); - This->ref--; + ref = InterlockedDecrement(&This->ref); /* destroy the object if there's no more reference on it */ - if (This->ref==0){ + if (ref == 0){ URLMonikerImpl_Destroy(This); return 0; } - return This->ref; + return ref; } /******************************************************************************

1 0

RE: patch: SHELL_ArgifyW expands env-vars - last try
by Jens Collin 23 Sep '04

23 Sep '04

I never get any response to my supplied patch. I assume that there's something more wrong with it, but I can't _guess_ what it is. Could anyone help me? /Jens -----Original Message----- From: wine-patches-admin(a)winehq.org [mailto:wine-patches-admin@winehq.org] On Behalf Of Jens Collin Sent: den 13 september 2004 20:15 To: wine-patches(a)winehq.org Subject: patch: SHELL_ArgifyW expands env-vars - last try Sorry for all the bouncing of email on this matter. All suggestions/corrections has been taken into consideration and applied to attached patch. Regards, Jens ---- changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).

2 2

Getting winebuild to work on HP-UX
by Firewall/CSI＠cimmetry.com 23 Sep '04

23 Sep '04

Hi all, As I mentioned in a previous post, I'm working on getting winelib to run on an HP-UX / PA-RISC system. The biggest problem I'm facing right now is dealing with all of the assembly code that is put into the .spec file by winebuild. I'm not an expert at assembly of any form, and I know absolutely nothing about PA-RISC assembly. I guess my main question is: why is so much assembly needed there - can some or all of it be replaced by C code (at least on platforms where you never need to interact with real windows libs - like sparc/solaris and pa-risc/hpux)? Any suggestions on how to get this code working on hpux would be really helpful! Warren

3 2

Re: shlwapi: Implement PathSearchAndQualify
by Alexandre Julliard 23 Sep '04

23 Sep '04

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > Implement PathSearchAndQualify and add a test. I think you need to throw a SearchPath() in there too. If you try with a simple file name without directory you'll see that the test fails. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: Help with GetConsoleWindow()
by Ewert, Mark 23 Sep '04

23 Sep '04

This is the trace just before the exception that is seen: 0017:trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\ws2_32.dll" : builtin 0017:trace:loaddll:load_dll Loaded module L"Z:\\home\\xscale_xactor\\sandbox\\MSVCR71.dll" : native 0017:trace:loaddll:load_dll Loaded module L"Z:\\home\\xscale_xactor\\sandbox\\MSVCP71.dll" : native 0017:trace:loaddll:load_dll Loaded module L"Z:\\home\\xscale_xactor\\sandbox\\CoSimClient.dll" : native 0017:trace:loaddll:load_dll Loaded module L"Z:\\home\\xscale_xactor\\sandbox\\plugin\\xscale\\ixpirqgui\\irqgui.dl l" : native wine: Unhandled exception (thread 001a), starting debugger... Is the problem in irqgui.dll? -----Original Message----- From: Saulius Krasuckas [mailto:saulius2@ar.fi.lt] Sent: Monday, September 20, 2004 1:17 PM To: Ewert, Mark Cc: wine-devel(a)winehq.org Subject: RE: Help with GetConsoleWindow() On Mon, 20 Sep 2004, Ewert, Mark wrote: > "wine: Unhandled exception (thread 000d), starting debugger... > WineDbg starting on pid 0x8 > Unhandled exception: page fault on write access to 0x41a417a4 in 32-bit > code (0x10007239). > In 32 bit mode." > > A window pops up that says: > > "Uhandled page fault on write access to 0x41a417a4 at address 0x10007239 > Do you wish to debug it?" Is this oming from another thread or even another process? IMHO, you should try running in some way similar to this: $ WINEDEBUG=+loaddll,+process,+tid wine ... to see more interesting info in the output of Wine. > When I click yes I get a dump of all the register/memory locations. Is > there anything in particular I should look for? IMO, no. Are you receiving an interactive prompt of "Wine-dbg>" in your console? If yes, better try typing command "bt" to get the backtrace, then. Maybe the "bt all" command would help more. My $.01, my $.01.

2 1

Moving some 16-bit code
by Ge van Geldorp 23 Sep '04

23 Sep '04

dlls/shell32/control.c contains some 16-bit code (function RunDLL_CallEntry16), which I would like to separate out. I wonder if the attached patch is the correct way to do that? On Win2k export 122 is just a stub. Maybe it would be ok to turn our export 122 into an empty function too? Ge van Geldorp. Index: control.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/control.c,v retrieving revision 1.20 diff -u -r1.20 control.c --- control.c 12 Jul 2004 19:50:56 -0000 1.20 +++ control.c 22 Sep 2004 19:28:18 -0000 @@ -456,30 +456,6 @@ return Control_FillCache_RunDLLW(hWnd, hModule, w, x); } - -/************************************************************************* - * RunDLL_CallEntry16 [SHELL32.122] - * the name is probably wrong - */ -void WINAPI RunDLL_CallEntry16( DWORD proc, HWND hwnd, HINSTANCE inst, - LPCSTR cmdline, INT cmdshow ) -{ - WORD args[5]; - SEGPTR cmdline_seg; - - TRACE( "proc %lx hwnd %p inst %p cmdline %s cmdshow %d\n", - proc, hwnd, inst, debugstr_a(cmdline), cmdshow ); - - cmdline_seg = MapLS( cmdline ); - args[4] = HWND_16(hwnd); - args[3] = MapHModuleLS(inst); - args[2] = SELECTOROF(cmdline_seg); - args[1] = OFFSETOF(cmdline_seg); - args[0] = cmdshow; - WOWCallback16Ex( proc, WCB16_PASCAL, sizeof(args), args, NULL ); - UnMapLS( cmdline_seg ); -} - /************************************************************************* * CallCPLEntry16 [SHELL32.166] * Index: shell.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell.c,v retrieving revision 1.61 diff -u -r1.61 shell.c --- shell.c 15 Jun 2004 18:27:50 -0000 1.61 +++ shell.c 22 Sep 2004 19:28:18 -0000 @@ -657,3 +657,27 @@ return HINSTANCE_16(seiW.hInstApp); } + + +/************************************************************************* + * RunDLL_CallEntry16 [SHELL32.122] + * the name is probably wrong + */ +void WINAPI RunDLL_CallEntry16( DWORD proc, HWND hwnd, HINSTANCE inst, + LPCSTR cmdline, INT cmdshow ) +{ + WORD args[5]; + SEGPTR cmdline_seg; + + TRACE( "proc %lx hwnd %p inst %p cmdline %s cmdshow %d\n", + proc, hwnd, inst, debugstr_a(cmdline), cmdshow ); + + cmdline_seg = MapLS( cmdline ); + args[4] = HWND_16(hwnd); + args[3] = MapHModuleLS(inst); + args[2] = SELECTOROF(cmdline_seg); + args[1] = OFFSETOF(cmdline_seg); + args[0] = cmdshow; + WOWCallback16Ex( proc, WCB16_PASCAL, sizeof(args), args, NULL ); + UnMapLS( cmdline_seg ); +} Index: shell32.spec =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell32.spec,v retrieving revision 1.87 diff -u -r1.87 shell32.spec --- shell32.spec 6 Sep 2004 20:24:10 -0000 1.87 +++ shell32.spec 22 Sep 2004 19:28:19 -0000 @@ -115,7 +115,6 @@ 119 stdcall IsLFNDrive(ptr) IsLFNDriveAW 120 stdcall FileMenu_AbortInitMenu () 121 stdcall SHFlushClipboard () - 122 stdcall -noname RunDLL_CallEntry16(long long long str long) #name wrong? 123 stdcall SHFreeUnusedLibraries () 124 stdcall FileMenu_AppendFilesForPidl(long ptr long) 125 stdcall FileMenu_AddFilesForPidl(long long long ptr long long ptr) Index: shell.spec =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell.spec,v retrieving revision 1.10 diff -u -r1.10 shell.spec --- shell.spec 26 Sep 2003 04:32:20 -0000 1.10 +++ shell.spec 22 Sep 2004 19:28:19 -0000 @@ -29,6 +29,8 @@ 102 pascal -ret16 RegisterShellHook(word word) RegisterShellHook16 103 pascal ShellHookProc(word word long) ShellHookProc16 +122 pascal RunDLL_CallEntry16(long long long str long) #name wrong? + 157 stub RESTARTDIALOG # 166 PICKICONDLG

2 1

Promoting WINE
by Andreas Rosenberg 23 Sep '04

23 Sep '04

Hello Wine developers, perhaps some guys will remember me. I'm working for a small software company making a tool for FMEA and risk management. Late last year I managed to make our application work with Wine by submitting some patches. Our company held it's anual user meeting this week in Pforzheim (Germany) where about 150 people, working mostly for automotive companies (Daimler Crysler, BMW, BOSCH, VALEO, AUTOLIV, TRW etc.) attended. Since we had some requests for a Linux version of our software, I could arrange a short presenation of WINE in combination with our software. Two people talked to me after the presentation,indicating that they have a strong interest in this topic and asked for a german documentation how to install Wine. Perhaps this presentation has put a seed into certain heads and will show them ways to alternatives using software written for Windows. I thought, this might interest some of the developers. Regards Andy

1 0

Re: [4/5] GetWindowLongPtr: Windows
by Dmitry Timoshkov 23 Sep '04

23 Sep '04

"Robert Shearman" <rob(a)codeweavers.com> wrote: > - if (!(context.Eax = GetWindowWord( HWND_32(hwnd), GWL_HINSTANCE ))) context.Eax = context.SegDs; > + if (!(context.Eax = GetWindowWord( HWND_32(hwnd), GWLP_HINSTANCE ))) context.Eax = context.SegDs; GetWindowWord above probably should be replaced by GetWindowLongPtrW. And all appropriate ANSI variants of the GetWindowLongPtr call should have been replaced by a unicode one while you were at it. Of course that's not critical at all, just a nit pick. -- Dmitry.

3 2

winemaker/winelib problems
by Tim Ruehsen 23 Sep '04

23 Sep '04

Hi, i want to compile a small MFC based app using winelib/winemaker. The system is Debian SID (upto date, daily patched) (wine 20040716). As I understood from doc 'winelib-user/mfc-compiling' I have to compile MFC first. I copied dir 'atlmfc' from VC7 onto my machine, cd'ing into atlmfc/src/mfc und executing: winemaker --mfc . No errors. Now ./configure --with-wine=/usr/bin --with-wine-includes=/usr/include/wine/windows --with-wine-libraries=/usr/lib --with-wine-dlls=/usr/lib/wine --with-mfc=/usr/oms/atlmfc --with-atl-includes=/usr/oms/atlmfc/include says 'checking for libntdll.so... configure: error: Could not find the Wine dlls (libntdll.so)' And really: libntdll.so is not on my system, but I can find /usr/lib/wine/ntdll.dll.so Now I try to work around it by making a symbolic link ln -s /usr/lib/wine/ntdll.dll.so /usr/lib/wine/libntdll.so Again calling ./configure with the same options as above results in 'checking for atldef.h header... configure: error: Could not find the ATL includes' atldef.h does exist: -rwxr--r-- 1 oms users 7569 Sep 23 13:09 /usr/oms/atlmfc/include/atldef.h I played around with some other options to ./configure but the result stays the same. I edited configure to wrok around it, but I get similar errors with other includes (which exist as well). Can anyone give me a hint what to do? (Yes, I read the docs, but they are somewhat confusing... looks like something is missing there). Thanks for your patience! Tim

1 0

Re: icmp - allow building on MS_VC and Mingw
by Hans Leidekker 23 Sep '04

23 Sep '04

On Thursday 23 September 2004 06:02, Steven Edwards wrote: > Feel free to drop the gettimeofday part from this patch. There are 16 > other source files where we call gettimeofday in Wine and I am sure if > you dont accept it I can come up a good implementation in libwine. Why not use Windows time functions directly in ICMP? Reimplementing gettimeofday on top of Windows time fuctions doesn't seem like an ideal solution for ReactOS nor Wine. In Reactos you'd already have unnecessary loss of precision but even more so in Wine since we'd be doing: gettimeofday() -> GetSysTemTimeAsFileTime() -> gettimeofday(). Not to mention the maintenance burden of a Unix api in Reactos and Wine. -Hans

1 0

RFC: more Windows-NT like user directories?
by Juan Lang 23 Sep '04

23 Sep '04

Folks, I'm still working on the shell path functions, and I was thinking of changing the directory layout for the shell directories (desktop, start menu, my documents and whatnot) from the Windows 95-ish way to the NT-ish way. That is, rather than being children of c:\windows, they'd generally be children of c:\documents and settings\<username>. Any complaints? --Juan _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

7 17

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