- Wine-Devel - list.winehq.org

Re: Moved some local variables from StartServiceCtrlDispatcherA/W to service environment block
by Alexandre Julliard Sept. 29, 2004

Sept. 29, 2004

"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 Sept. 29, 2004

Sept. 29, 2004

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 Sept. 29, 2004

Sept. 29, 2004

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 Sept. 28, 2004

Sept. 28, 2004

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 Sept. 28, 2004

Sept. 28, 2004

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 Sept. 28, 2004

Sept. 28, 2004

> 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 Sept. 28, 2004

Sept. 28, 2004

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(a)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 Sept. 28, 2004

Sept. 28, 2004

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 Sept. 28, 2004

Sept. 28, 2004

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 Sept. 28, 2004

Sept. 28, 2004

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