September 2004 - Wine-devel

main menu bar problem
by Attila Csosz 30 Sep '04

30 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 29 Sep '04

29 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