October 2002 - Wine-Devel - list.winehq.org

Re: GetComputerName() question

by Martin Wilck

Am Mit, 2002-10-30 um 20.25 schrieb Alexandre Julliard: > Because users are not going to edit the registry if their Unix > hostname changes so it will always be wrong. Now if the problem is the > FQDN then it should be trivial to truncate it to just the hostname. I can't help myself - I think the current implementation in wine isn't correct, at least not as correct as it could be. http://www.jsifaq.com/SUBH/tip3900/rh3982.htm It wouldn't be hard to fix this, but the fact that this stuff happens during Wine initialization scares me off. That's why I want to know why this is done so early. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Oct. 31, 2002

Re: miscemu/wine gets into the way in map_image

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> However when unzip has unpacked the 160 MByte file and the Setup >> should start, a crash happens, and the debugger startup stops with >> "Memory exhausted". The same happens when I run in winedbg: Loaded >> debug information from ELF >> '/home/bon/tmp/wine/compile/wine/miscemu/wine' (0x00000000) >> Breakpoint 2 at 0x4000c714 (_end+0xf7fec) Memory exhausted. Alexandre> You probably need reduce the base address a bit to leave more Alexandre> space for malloc(). Try changing the 0x3ff to 0x3f0. Now of Alexandre> course we shouldn't be using malloc, so that hack would be a Alexandre> good way to enforce that <g> Alexandre, could we get this into the wine tree? At least one person stumled across that with the same application I had. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 31, 2002

Re: SetWindowHookEx

by Shachar Shemesh

So you mean to say that my windows X-Eyes implementation won't work on WINE????? Damn. Anyone knows of any Unix port of that program? Shachar No, wait. I'm using a mouse hook. Maybe it'll work after all. Sh. Alexandre Julliard wrote: >steve.lustbader(a)philips.com writes: > > > >>My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. >>Currently, the wine implementation tells me >>"fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right" >>when I try to use it. I'd like to implement this so I can get my app to >>run, but I'm not sure where to start, since I don't know why it >>"won't work right." Any hints/suggestions? >> >> > >I'm working on it. Basically it won't work right across processes at >this point; if you have a single process it should be OK. > > >

Oct. 31, 2002

Re: GetComputerName() question

by Martin Wilck

Am Mit, 2002-10-30 um 20.25 schrieb Alexandre Julliard: > Because users are not going to edit the registry if their Unix > hostname changes so it will always be wrong. Now if the problem is the > FQDN then it should be trivial to truncate it to just the hostname. You did not explain why this must happen at wine initializaiton time (why is this code in win32/init.c?). Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Oct. 31, 2002

Re: Versions & mass-appeal

by Shachar Shemesh

Johan Gill wrote: >Even with perfectly working builtin dlls, one needs overrides for the >native dlls that are proprietary, or the loading will fail. Or is this a >bug? > >/Johan Gill, johane(a)lysator.liu.se > > > The way I see it, no windows installs of wine should have dll load order set to "native, builtin" for all DLLs. The rational is that, as no DLL originally came from a native windows environment, all dlls present in the system are from various installs. It was therefor the application's install decision to override the dll available at the time of install with a new version. For that to properly work, it must be possible to query the builtin DLLs version with the APIs available to standard installers, and have the version reported for our DLLs be comparable to DLLs of same functionality available on Windows. I am not sure where that stands at the moment, however. Shachar

Oct. 31, 2002

Re: Debugging advice

by David Laight

> That's because of differences between the ELF and PE binary > formats. For instance, each Windows dll is in its own namespace, while > ELF dlls share a single namespace; so we need to do linker tricks to > simulate the PE behavior. Did anyone consider writing a different elf interpreter (normally ld.elf_so) so that a different method of handling the namespaces could be used? I certainly found that (on netbsd) part of the reason for the slow start of programs like mozilla was the continual searching for symbols in all of the shared libraries that make up the program body (because they are searched for EVERY symbol). David -- David Laight: david(a)l8s.co.uk

Oct. 31, 2002

Re: EMF bug

by Joerg Mayer

On Wed, Oct 30, 2002 at 09:46:55PM -0600, Jeremy White wrote: > Near future, by the way, means that we're shipping on Friday, I'd like to see an annoucement on wine-announce when it's out. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Oct. 31, 2002

Re: GetComputerName() question

by Martin Wilck

Am Mit, 2002-10-30 um 20.25 schrieb Alexandre Julliard: > Because users are not going to edit the registry if their Unix > hostname changes so it will always be wrong. Now if the problem is the > FQDN then it should be trivial to truncate it to just the hostname. Sorry, how many machines are out there that change their host name on a regular basis, so that the registry name would "always" be wrong ? The way Samba does this is IMO reasonable: "netbios name (G) - This sets the NetBIOS name by which a Samba server is known. By default it is the same as the first component of the host's DNS name." I'd propose: If the registry contains an explicit ComputerName entry, use it as Netbios name; otherwise, use the Unix hostname. This would affect only the users that enter a Netbios name in their registry, and thus not those with changing host names that you're worried about. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Oct. 31, 2002

Re: Versions & mass-appeal

by Johan Gill

On Wed, 30 Oct 2002, Dimitrie O. Paun wrote: > > - Getting the right set of dlloverrides and registry entries correct > > for a large portion of software is irritating. [snip] > > We should aim at delivering a 0.8/0.9/1.0 that does not require native > DLLs to run apps. And so, there should be no need for dlloverrides... Even with perfectly working builtin dlls, one needs overrides for the native dlls that are proprietary, or the loading will fail. Or is this a bug? /Johan Gill, johane(a)lysator.liu.se

Oct. 31, 2002

Re: richedit

by Michael Stefaniuc

On Wed, Oct 30, 2002 at 08:58:54PM -0500, Vincent Béron wrote: > Le mer 30/10/2002 à 20:44, Francois Gouget a écrit : > > On Thu, 31 Oct 2002, Michael Stefaniuc wrote: > > > is somebody working on the richedit dll? I encountered 3 unknown RTF > > > control words and wanted to add them but I got scared by the overzealous > > > use of #define's in rtf.h . My first impuls was exchange that with some > > > enum's, but i thought i better ask here before i do the work in vain. > > > > Isn't enum a C++ specific feature? > > If so then we cannot use it in Wine. > > No, it's part of standard C. > http://www-ccs.ucsd.edu/c/types.html#Enumerations And we already use it quite a lot: brasov:~/work/wine$ find -name \*.h | xargs grep -w -l enum | wc -l 86 bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Oct. 31, 2002