All the news that fits, we print.
This week, 41 posts consumed 125 K. There were 23 different contributors. 9 (39%) posted more than once. 12 (52%) posted last week too. The top 5 posters of the week were:
|
DeadKeys in Microsoft and X11 worlds | 17 Jan 2001 00:00:00 -0800 | Archive |
---|---|---|
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:
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_CHAR
s 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:
|
Chinese Wine | 21 Jan 2001 00:00:00 -0800 | Archive |
---|---|---|
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 | 24 Jan 2001 00:00:00 -0800 | Archive |
---|---|---|
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:
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\HandoffPriorities
Think we can ignore this key safely.
|
Linux on PPC (and OSX) | 25 Jan 2001 00:00:00 -0800 | Archive |
---|---|---|
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 | 01 Jan 1919 00:00:00 -0800 | Archive |
---|---|---|
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.
|
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.