![[LWN Logo]](/images/lcorner.png) |
|
![[Timeline]](/images/Included.png) |
From: Eric Pouech <Eric.Pouech@wanadoo.fr>
Newsgroups: comp.emulators.ms-windows.wine
To: "Wine announce (WWN publish)" <wine-announce@winehq.com>
Subject: Wine Weekly News #80 (2001 Week 05)
Date: Tue, 30 Jan 2001 21:58:10 +0000
This is a multi-part message in MIME format.
--------------85E665186836522EF77DE1E7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
please find enclosed this week edition. Enjoy your reading.
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
--------------85E665186836522EF77DE1E7
Content-Type: text/plain; charset=iso-8859-1;
name="wwna.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="wwna.txt"
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for January 29,
2001 .
_________________________________________________________________
_________________________________________________________________
Keeping track of Wine
_________________________________________________________________
* Alexandre Julliard kept cleaning up DLLs, this time dealing with
the threadsafe errno and X11 critical sections, and DLL startup
sequences. He also converted a large number of Xpm bitmaps into
proper user32 resources, and made 0xdeadbeef messages show the
importing dll.
* Other Workers/Bugfixers: Gerard Patel (misc), James Juran (misc),
Eric Pouech (multimedia), Jon Griffiths (Unicode, msvcrt), Patrik
Stridvall (winapi_check), Guy Albertelli (common controls), Marcus
Meissner (joystick, ddraw, msvideo), Ulrich Weigand (message queue
threadsafety), Matthew Clarke
+ CodeWeavers: John R. Sheets (docs, mozilla-control registry
entries), Jeremy White (winelauncher, shell links), François
Gouget (Winelib), Chris Morgan (wineinstall, docs), Dmitry
Timoshkov (edit control), Ulrich Czekalla (listview), Huw D M
Davies (wininet, printing), Eric Kohl (world transforms,
metafiles), Josh DuBois (portability), Andreas Mohr (misc),
Susan Farley (window positioning), Martin Pilka (registry)
+ Macadamian: James Hatheway (winsock)
+ TransGaming: Ove Kåven & Gavriel State (dinput)
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 41 posts consumed 125 K. There were 23 different
contributors, 9 (39%) posted more than once, and 12 (52%) posted
last week too.
The top posters of the week were:
* 4 posts in 13 K by "Dmitry Timoshkov" <dmitry@sloboda.ru>
* 4 posts in 10 K by Martin Pilka <mpilka@codeweavers.com>
* 3 posts in 8 K by Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
* 3 posts in 8 K by David Elliott <dfe@infinite-internet.net>
* 3 posts in 8 K by "Alexandre Julliard" <julliard@winehq.com>
* 3 posts in 4 K by "Ove Kaaven" <ovehk@ping.uio.no>
* 3 posts in 13 K by Ulrich Weigand
<weigand@immd1.informatik.uni-erlangen.de>
* 2 posts in 8 K by Chris Morgan <cmorgan@wpi.edu>
* 2 posts in 5 K by gerard patel <gerard.patel@asi.fr>
DeadKeys in Microsoft and X11 worlds Issue
Joao Clemente reported some issues with his Portuguese keyboard:
I am trying to use wine (I installed this week's package) but once
again I found my keyboard doesn't work properly...
I can't have the following chars right: \ | ` ' » «
I think that it's a problem related with "dead keys" (? I'm not
even sure of WHAT are dead keys, sorry...) 'cause I've looked
somewhere in windows/keyboard.c and it has there a comment saying
something like "It works except for dead keys"
A dead key is used to generate complicated characters from the
keyboard. For example (in French, sorry I couldn't resist), the ê
character (e with diaresis ^), can be generated by hitting on the
keyboard the ^ key, then the e key. The first hit will generate a dead
key, meaning it has not to be treated as a regular character but
rather as a modifier on the next character to be entered.
Dmitry Timoshkov answered a bit to Joao's questions:
Actually support for dead keys can be implemented now, since Alexandre
added support for composite unicode characters. I even wrote
several tests to prove the concept and do 2->1 and 1->2 character
conversions in WideCharToMultiByte and MultiByteToWideChar. But I
have some problems:
1. Actually I don't know how to generate dead key sequence that
will modify next character, because cyrillic has no this
"feature".
2. Accent characters in different code pages has different
mappings to unicode characters. Perhaps we just have to
create internal table with mapping [combining character in
code page] -> [combining character in unicode]?
Ove Kaaven went even further:
It's really not that hard... under Windoze, the keyboard driver keeps
some internal static variable that holds the last deadchar used
(the last deadchar fed to ToAscii/ToUnicode).
When a deadkey is given to ToUnicode, it stores the deadchar into
its static variable and returns -1 and the dead character. When
the TranslateMessage code sees a return value of -1, it generates
a WM_DEADCHAR using the returned character.
On the subsequent ToUnicode invocation, it sees that a deadchar
has been stored, and tries to combine it with the incoming
character. If it's able to combine them, it returns the combined
character and the return value 1. If not, it returns both the
uncombined dead character and the incoming character, and the
return value 2. Also, it clears the static variable, of course...
TranslateMessage does send two WM_CHARs when ToAscii/ToUnicode
returns 2, if I remember right, though this case is often
accompanied by a beep under Windows.
Then, Dmitry (with some indication from Ove) tried to iron this out.
After some first unfruitful tries, and the help of some other Russian
folks, Dmitry felt he had enough information to implement proper dead
keys support. However, as Ove already put up, there was two possible
paths to follow:
There are two approaches in implementing support for dead keys:
1. Do all the character composing in Wine itself, completely
ignoring X. It will allow Wine to have full control over
keyboard, but will completely ignore characters about Wine is
unaware and any custom composing, that the user could have in
his/her Compose file.
2. Delegate all the character composing tasks to Xlib. This will
allow the user to have his/her familiar environment, but will
lead to some cases, when some keyboard activity will be
interpreted differently in Wine then in Windows: for instance
Ctrl<T><plus><plus> will produce "#" numbersign instead of,
say, call font selection dialog on Ctrl<T>. But this
misinterpretations could be easy fixed by the user, because
only he/she knows what behavior they want to have.
Dmitry (as Ove at first glance and Joao) preferred to use second
option, even if, as Dmitry noted later on, "Having Xlib to do all dead
key composition is an easy way to go. But there are (at least in
theory) another drivers (EdNote: for display, like a pure console
one). Having dead key support in Wine itself will simplify creating
those drivers, assuming that new driver should not worry about
character composing, only deliver keystrokes. But such an internal
support for dead keys in Wine core should not affect any driver at
all: driver just will never say "I have dead key for processing", it
just will silently process it itself."
However, no patch has been committed yet regarding this missing
feature...
Chinese Wine Issue
On the matter of internationalization, Howard Chan stressed some other
areas:
I was playing with wine and try to get some Chinese windows games
working (old games in the win95 era), but it seems that there are
problems with Chinese support. In particular, fonts are not right
and I can't get it to display the correct font. I'm using
wine-20010112 snapshot.
While hacking around (the docs on winehq has not much use since it
is too outdated and file locations are totally changed) it seems
that the cht (zh_TW locale) is using the wrong codepage
(traditional Chinese should be using codepage 950) and it seems
that the definition is not complete. I would like to help but the
docs are outdated and I can't do much without understanding how
the locales work on wine. I tried to change the
dlls/kernel/nls/cht.nls to use codepage 950 but still it can't get
the font works. Since my fonts work in X11 and mozilla I think
it's wine that is causing the problem.
BTW, Japanese support seems OK since I can successfully load
Japanese window games with correct text displayed, so the
multibyte character locale support should be no problem.
Aric Steward welcomed the help on this area of Wine. Aric also
suggested to map some Windows font to their X11 counterparts (using
the [fonts] section from the ~/.wine/config file), and suggested using
the -isas-song ti- X11 fonts for this purpose.
Howard didn't like the proposal:" -isas-song ti- is a GB font, which
is used in Communist China (zh_CN). Taiwan and Hong Kong (zh_TW and
zh_HK) uses big5 fonts *-big5-0 which is not included in the standard
XFree86 distribution.
One thing that may be of interest. xselfont cannot display my Chinese
fonts also (just blank on the sample text area), but mozilla and
windowmaker can use it without problem.
"
So further posts appeared, still meaning that the Chinese (including
Taiwan and Hong Kong variants) needs some more work to be done.
Registry and main branches Issue
Martin Pilka wrote:
File ~/.wine/userdef.reg is quite mysterious to me. It seems it
contains some keys from HKEY_LOCAL_MACHINE, HKEY_USERS/.DEFAULT,
HKEY_USERS/%username%. HKEY_LOCAL_MACHINE is also contained in
system.reg file, and HKEY_USERS/%username% in user.reg file. what
is that duplicity good for? which value takes precedence?
Alexandre Julliard answered: "userdef.reg is supposed to contain only
HKEY_USERS/.Default; but it seems a typo crept it at some point that
causes it to contain the whole registry."
Alexandre provided a one line patch to solve this. Martin confirmed it
solved some issues. However, he continued
Ok, I see. That patch helped a bit. However:
system.reg --> HKEY_LOCAL_MACHINE
userdef.reg --> HKEY_USERS/.DEFAULT
user.reg --> HKEY_USERS/%username%
Where is the place for HKEY_USERS/Software/... key? My native
windows registry contain one. I'm able to load it properly where
it belongs, but after wine exit that key will end in userdef.reg
file. Next time i run regedit (and load only from home registry)
the key is under HKEY_USERS/.DEFAULT again, What is wrong.
Ove Kaaven answered:"There shouldn't be such a thing. What kind of
idiot program created that? The closest correct thing would be
HKEY_CURRENT_USER/Software, which would map to
HKEY_USERS/%username%/Software..."
Juergend Schmied went further:"The crapy program is the microsoft
dialer.
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Telephony\Handoff
Priorities
Think we can ignore this key safely.
"
Linux on PPC (and OSX) Evolution
Josh DuBois still struggling to let Wine run on PPC wrote:
How closely is Wine tied to the ELF format? I've (finally! :-) ) got
the apps in the programs/ dir running on linuxppc, so I tried to
scoot the code over to OSX just to see what happened. Of course no
dlopen on OSX ==> no compilation. OSX uses Mach-O binaries, rather
than ELF. A dlopen() "equivalent" for Mach-O exists, but I've
never called dlopen() in my life, so I'm not sure on what
criterion to compare them. Does anyone know, broadly, what the hot
spots will by trying to make wine use a different shared object
format?
Ulrich Weigand answered:
Well, Wine only needs the basic functionality of dlopen, dlclose,
dlsym, which are rather equivalent to LoadLibrary, FreeLibrary,
and GetProcAddress. Anything that allows some sort of run-time
dynamic linking must really provide this functionality IMO... You
should be able to implement the corresponding routines in
library/port.c.
There might be some further dependencies to the ELF format,
however: e.g. we rely on the fact that the .init and .fini
sections can be used to implement global constructors /
destructors. (This is not a feature of the ELF format, strictly
speaking, but of the way ELF loading is done by the Linux
toolchain and dynamic loader. OSX probably has something similar.)
Java and USER Issue
David Goodenough did some testings with Wine 20010112 and tried the
Windows 1.1.8 java runtime environments:
The Sun one fails with the GetFastQueue16 error that I mentioned with
the last drop. Does anyone know what needs to be done to build a
default queue. I put in a suggestion last time but no one reacted
to say whether it was the right approach. Also there was the
question about how it should be deleted when the thread is
cleared. The Windows SDK file I have does not seem to list
GetFastQueue16, so I do not know what the rules are.
The IBM one just hangs. No errors, no GetFastQueue16 error, but a
hard and solid loop. I will try to use trace to see what is
happening.
Ulrich Weigand went on with some explanation:
GetFastQueue16 is an undocumented kernel routine that is used in Win9x
to implement the specification that all threads except the main
thread by default don't have a message queue; when they call the
first 'GUI' routine that requires a message queue, one will be
created on the fly.
This is done by having every routine that needs to access the
thread's message queue call GetFastQueue16 to retrieve the queue.
If the queue is already present, it will be simply returned. If
the thread doesn't yet own a queue, one will be created.
GetFastQueue16 only gives the warning message if it tried to
create a message queue, but this failed for some reason. This is a
situation that should never occur, really ...
In fact, the only situation I could understand GetFastQueue16 to
fail would be if the application doesn't load the USER subsystem,
so that the callout from KERNEL will not be present.
The callout mechanism provides a way for KERNEL DLL pair to call
functions in USER even if dependencies between DLL would be the other
way around. It's just a table of function pointer which are filled
with the addresses of the needed USER functions when USER is loaded.
Ulrich then asked from some traces to shed some light. Gérard Patel
continued the testing and confirmed Ulrich's thoughts:
I did not include the trace as it's rather large but what happens is
clear enough: the main exe loads implicitly KERNEL32 but not USER
- USER is loaded implicitly by a DLL loaded by LoadLibrary.. So
when the kernel initialization is done, USER is not yet loaded.
It's unusual but seems perfectly valid IMO.
Ulrich answered:
Hmmm. Strictly speaking, if an app dynamically loads USER, it can also
dynamically unload USER; we'd have to take care that we invalidate
the Callout pointers if this happens.
and provided a patch to fix the issue. Gérard confirmed this actually
fixed the problem.
Credits: [1]Doug Ridgway, [2]Eric Pouech, and [3]Ove Kåven.
_________________________________________________________________
References
1. mailto:ridgway@winehq.com
2. mailto:pouech@winehq.com
3. mailto:ovek@winehq.com
--------------85E665186836522EF77DE1E7--