- Wine-Devel - list.winehq.org

WinZip
by Mike Hearn Nov. 13, 2002

Nov. 13, 2002

OK, I remembered reading about how WinZip was nearly Gold but not quite. There was a problem with the richedit control. If I install the richedit control into Crossover 1.3.1 from here http://www.allerasoft.com/download/ I can view comments in WinZip OK. Unfortunately if I do this (try with the example zip file in the winzip directory) it crashes on exit. I might try some proper traces this afternoon, but is there a reason Wine can't mirror the richedit update program and install it a la DCOM? -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

3 4

Re: ComputerName, take 2
by Alexandre Julliard Nov. 13, 2002

Nov. 13, 2002

Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> writes: > @@ -1741,7 +1810,6 @@ > RtlOpenCurrentUser( KEY_ALL_ACCESS, &hkey_current_user ); > > _set_registry_levels(0,0,0); > - _allocate_default_keys(); > if (PROFILE_GetWineIniBool(RegistryW, load_win_reg_filesW, 1)) > _load_windows_registry( hkey_local_machine, hkey_current_user, hkey_users_default ); > if (PROFILE_GetWineIniBool(RegistryW, load_global_reg_filesW, 1)) > @@ -1749,6 +1817,7 @@ > _set_registry_levels(1,0,0); > if (PROFILE_GetWineIniBool(RegistryW, load_home_reg_filesW, 1)) > _load_home_registry( hkey_local_machine, hkey_current_user, hkey_users_default ); > + _allocate_default_keys(); > _init_registry_saving( hkey_local_machine, hkey_current_user, hkey_users_default ); > NtClose(hkey_users_default); > NtClose(hkey_current_user); This bit is going to break the default keys, it will make them stored into the user registry files. I'd suggest moving the computer name stuff out of allocate_default_keys() and into an internal function in computername.c, that would be called during kernel init. This will also avoid handling the same configuration option in two different dlls. -- Alexandre Julliard julliard(a)winehq.com

2 1

TODO & FAQ moved
by Dimitrie O. Paun Nov. 13, 2002

Nov. 13, 2002

Hi all, Please note that the FAQ, and the TODO got moved to a new location: http://www.dssd.ca/wine/Wine-0.9-TODO.html http://www.dssd.ca/wine/Wine-FAQ.html The old location still works for your convenience, but it will go away (probably soon). Hope this doesn't inconvenience anyone too much. -- Dimi.

3 5

Re: Documentation build changes (try 3)
by Alexandre Julliard Nov. 13, 2002

Nov. 13, 2002

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Changelog: > Allows the building of separate guides rather than only the big one. > Determines the name of the installed docbook filter (db2html or > docbook2html, etc.) in configure, defaulting to false if absent. The $(addsuffix) etc. make macros are not portable, please avoid them. Also I don't think we need all these targets, the current html/ps/pdf distinction is enough IMO. I do agree that building the books separately is a good idea, in fact this should probably be made the normal behavior; I doubt many people want to read the complete docs in one piece... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winedbg
by Greg Turner Nov. 12, 2002

Nov. 12, 2002

On Tuesday 12 November 2002 03:25 pm, Eric Pouech wrote: > this patch fixes a regression recently introduced in string printing > it ensures that we don't loop for ever after we encountered the > terminating '\0' char > A+ thank you! this has been driving me nuts and I hadn't found the time to fix it myself. -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

Re: rundll32 utility
by György 'Nog' Jeney Nov. 12, 2002

Nov. 12, 2002

> Changelog: > - added rundll32 utility Would it be possible to simply implement the 16-bit rundll from this code? I havnt actually looked at this or anything, just thinking.... nog.

2 1

Cool Edit Pro vs. Wine/WineX
by Tom Hibbert Nov. 12, 2002

Nov. 12, 2002

Hi all, In my continuing quest for some kind of professional-level audio editing under Linux, I today tried to get Cool Edit Pro 2 to run using Wine/WineX. Both were able to install the demo version successfully but only WineX was able to make it start at all. Under WineX, the splash screen displayed successfully but appeared to hang when the application attempted "Resetting Menus". When I ran a trace it appeared that the application entered some kind of infinite loop, continually rescanning its plugins menu entries, and then entering into some kind of argument with xfs over which fonts were and werent available, before beginning the loop again. Any tips would be most appreciated. Tom Hibbert Work: someday Home: +649 815 1838 Obtain my GPG Key from: http://cryptocracy.hn.org/pubkey.txt

2 1

Wine's compatibility lists (updated)
by Carlos Lozano Nov. 12, 2002

Nov. 12, 2002

Hello, It includes 3 lists, a gold list with applications what are working almost 100% in wine, a silver list with application what could be working in wine with some work in them, and the full list with every test done :) Regards, Carlos. -- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.epsxe.com

6 7

wine button click through page
by Mike Hearn Nov. 12, 2002

Nov. 12, 2002

Here's a prototype of the page that people would see when clicking on the wine button, I think this is more friendly than simply linking directly to the apps db. It has a rather linux centric point of view, I hope this doesn't get anybodys back up. I could add mention of the other platforms Wine works on (freebsd??) if wanted. Anyway, if this is alright would Jeremy Newman mind adding it to the new WineHQ site? Then I can start trying to get buttons/links up on the windows side of the web. ta -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

Re: Help support
by Ender Nov. 12, 2002

Nov. 12, 2002

I'll just add my specific reasoning (plus pro's and con's) for supporting Konq, and some words on how IWebBrowser may be implemented: - BIG Con: The KDE libraries are GPLed. We can ask the team to perhaps allow us to use it under the LGPL. As far as I am aware, the only reason the libraries are under the GPL is because QT is under the GPL. Since one of the major factors in using KHTML/KJS in WINE will be removing the QT dependency, I see no legal problems to it.. only a matter of if they are willing. If not, the workaround is to implement it as an executable and just use IWebBrowser to send messages/RPCs/whatever to the executable. Using this as a general approach actually has many benefits anyway: : The browser can be upgraded easily, without having to worry about version conflicts against other DLLs. This is a major plus, IMHO : It's far easier to merge upstream changes, as less major modifications would need to be made to the browser core : The rendering engine CAN be replaced easily between Mozilla, Konq, or any other browser code suitably modified to support our IPC mechanism. Even so, we do need to decide on a default to use in WINE cvs. Any IPC mechinism would simply require IWebBrowser calls to be passed from a fairly stubby DLL and COM interface to the browser. The only real modifications needed to a browser would be to understand these calls, and to be able to render to a specified GDI context/hwnd/whichever. --- Other ideas: - Pro: Startup speed is fantastic, and while Gecko is fast while loaded, I really don't think we can use the method Mozilla uses to keep it fast (always run a configured Gecko instance in the background). I don't think WINE should have the overhead or code mess that it would cause. - Con: KHTML and KJS do have a dependency on QT or at least QT-Embedded. Getting a quick and nasty implementation of KHTML (+KJS, which we will need for DHTML/Javascript support, almost all applications that use IWebBrowser use JS) running will be easy, replacing the QT dependencies with Windows GDI/Commctl calls is somewhat more work. - Pro: I know that KHTML is easy to expand in the realm of supporting other URL schemes (res:// etc will be needed in IWebBrowser). I'm not sure how Gecko's architecture works in this respect. - Ender > > - Gecko: the best (in terms of features/compatability/speed) rendering > > engine around. Also benefits from being very widely deployed at least > > on Linux. Note that soon Mozilla will be splitting into a GRE (gecko > > runtime environment), then an XRE (xul runtime) layered on top, with > > Mozilla being an "application" on top of that framework. When this > > happens, making the GRE a dependancy of Wine would not be such a big > > deal IMHO, it's only a few megs at the moment. > > > > * Pros: We get a high quality rendering engine that we know is > > powerful enough to do what we need, and when the GRE thing happens > > it'll be relatively easy to embed too. Already has IWebBrowser > > interfaces(bitrotted afaik). > > * Cons: Gecko codebase is huge and complex, adding whatever IEisms > > are > > necessary may be hard. Overhead of XPCOM etc. > > > I'll add something else here. > > Mozilla is an absolute pain to run on OpenBSD. The porting team have > recently worked out that they can get it to run as long as they > statically link it. > > I have no idea if the Gecko part is affected by this, and I'm aware that > Wine does not currently run on OBSD anyway, but why make things more > difficult. > > Konq runs happily so KHTML is probably no problem and I have not heard > of any problems with GtkHTML. >

4 7