wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

taking a stab at analyzing a debug log
by James Hawkins 30 Sep '04

30 Sep '04

Hi, I've been trying to get Easy CD Extractor to work for a while now, and the program ezcddax.exe is having some weird (possibly) scheduling and threading problems, so in the meantime I've looked at some of the other exe's that Easy Cd Extractor installed. One such exe is burn.exe. When I run this, it seemingly immediately exits. This is an interesting part of +relay: 0009:Call kernel32.GetModuleHandleA(00000000) ret=0040158a 0009:Ret kernel32.GetModuleHandleA() retval=00400000 ret=0040158a 0009:Call kernel32.GetModuleFileNameA(00400000,406cfc18,00000105) ret=0040114e 0009:Call ntdll.RtlAllocateHeap(40370000,00000000,0000020a) ret=404da841 0009:Ret ntdll.RtlAllocateHeap() retval=403a91d8 ret=404da841 0009:Call ntdll.LdrLockLoaderLock(00000000,00000000,406cfad4) ret=404eafce 0009:Ret ntdll.LdrLockLoaderLock() retval=00000000 ret=404eafce 0009:Call ntdll.LdrFindEntryForAddress(00400000,406cfad0) ret=404eafe0 0009:Ret ntdll.LdrFindEntryForAddress() retval=00000000 ret=404eafe0 0009:Call ntdll.LdrUnlockLoaderLock(00000000,00000009) ret=404eb02c 0009:Ret ntdll.LdrUnlockLoaderLock() retval=00000000 ret=404eb02c 0009:Call ntdll.RtlUnicodeToMultiByteN(406cfc18,00000105,406cfad4,403a91d8,00000 060) ret=404d2873 0009:Ret ntdll.RtlUnicodeToMultiByteN() retval=00000000 ret=404d2873 0009:Call ntdll.RtlFreeHeap(40370000,00000000,403a91d8) ret=404da871 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=404da871 0009:Ret kernel32.GetModuleFileNameA() retval=00000030 ret=0040114e 0009:Call kernel32.ExitProcess(00000001) ret=00401454 0009:Call ntdll.LdrShutdownProcess() ret=404f5bd0 It seems that the last system call burn.exe makes before exiting is GetModuleFileNameA. I added an ERR in this function to see what filename it was getting, and it is: err:module:GetModuleFileNameA filename: L"C:\\Program Files\\Easy CD-DA Extractor 7\\burn.exe" which is the path of the program. After this call, burn.exe starts the exit process. Maybe burn.exe didn't like the results from GetModuleFileName? I'm not exactly experienced with analyzing debug logs, so I'm probably way off, but hopefully I'll get better. -- James Hawkins

1 0

Re: MSCMS: implement OpenColorProfile{A,W} and CloseColorProfile
by Hans Leidekker 30 Sep '04

30 Sep '04

On Saturday 25 September 2004 20:29, Hans Leidekker wrote: > Changelog: > Implement color profile handles. > Implement OpenColorProfile{A,W} and CloseColorProfile. Is there anything wrong with this patch? -Hans

1 0

How to deal with C++ APIs in wine spec file
by Dan Kegel 30 Sep '04

30 Sep '04

Jia L Wu (jwu(a)cc.helsinki.fi) wrote: > 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. Did you know that MSVC and g++ have completely incompatible C++ name mangling? In other words, you can only call third party C++ dlls if you're compiling with MSVC, as far as I know. And you can't compile winelib apps with MSVC, since MSCV only generates Windows apps, not Linux apps. So you may be out of luck. Can you write a windows app rather than a winelib app? If so, then you are in business; you can even build it on Linux (by running msvc under wine, which I do fairly often). - 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

Problems with SpamAssassin
by Mike McCormack 30 Sep '04

30 Sep '04

Raphael is having some trouble sending mail to the lists winehq.org. Can we get him whitelisted? Mike

1 0

Strictify make_authors
by Francois Gouget 29 Sep '04

29 Sep '04

I'm not very familiar with this tool so all I can say is that it does not have compilation errors at startup and seems to behave rationally. Changelog: * tools/make_authors Switch to 'perl -w' and add 'use strict;'. Add prototypes to all functions. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

1 0

main menu bar problem
by Attila Csosz 29 Sep '04

29 Sep '04

Hi, We developed an application under windows with borland cbuilder 5 and now we want run under linux with wine (not using an windows partition). We have tried with the latest version ( compiled and installed from CVS ) under "debian testing" linux distribution. This is mainly an opengl application and almost everything works fine but the menu bar dont works, clicking to the menu bar but nothing happened. It seems there is a problem with opengl and the main window. We have tested an other application that uses opengl but with an MDI child window (this works, opengl area in MDI window, main menu in the main window). The original application doesn't have an MDI window. So I think the problem: the main menu is it in the opengl area. Is it possible? We've tested a third application : it has the same problem ( main menu cant be clicked, and this not an MDI application ) We have tried wine in debian-stable, debian-testing, CVS. Thanks for any help (no solution from wine-users) Attila

1 0

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel