follow-up on previous [HELP] messages

[yves-gablin at ifrance.com]

Here's some follow-up on some messages I posted some
time ago asking for help. Wine works again since
20010731, better than ever, if maybe a little slower.

[HELP] Fn keys:

This problem is still present. Here's a reminder:
I use Wine to run Stew, an Atari ST emulator, a
Winston0.5 derivate.
While using the emulator, I can't use the Fn keys.
For example, if the program's asking to press F1 for
this and F2 for that, I can do neither.
I don't know if the problem lies with Wine, Stew, or
the combination. I tried to use the only Fn key used
by Wine: Alt-F4. Unfortunately, Alt-F4 is used by
gnome, and if I have 2 windows in the Wine desktop
and I press Alt-F4 then the entire Wine desktop is
closed instead...

[HELP] file access:

This problem is also still present. Here's a
reminder:
While using Stew, I can't access ANYNAME.ST files
(these are normal files which contain the image of a
floppy disk, most based on a msdos file-system, but
all inside a single file).
I "Insert Disk A:" in Stew, then I choose the xxx.ST
file in the Wine file selector. I valid my choice and
then: Wine disapears (exit or crash...). I don't know
if the problem lies within Wine, Stew, or the
combination.

[HELP] DPMI:

This problem is still present. Here's a reminder:
Every once in a while, I try to run a dos program in
wcmd (unix compiled & launched). My main purpose is
to test Atari ST emulators (I don't own a copy of
Windows).
Always, the dos program wants to access memory in
"real mode". There's something about the first 64Ko
of memory, then it always ends with a message about
there being no "DPMI".
[HELP] mouse:

This problem is SOLVED! Good! Here's a reminder:
>>>>>
I use Wine to run Stew in a 800x600 Wine Desktop, in
managed=Y (or sometimes =N) mode.
While in Wine only, no problem. While USING Stew, the
mouse behaved strangely: the ST emulator runs inside
the Wine Desktop in full screen and the ST mouse
pointer follows the movements of the mouse but:
- The pointer seemed to be stuck to an invisible
rectangle that was smaller than the full screen.
- When I tried to move the pointer past this
invisible rectangle's boundaries, the pointer was
hurried back (in the opposite direction) to a point I
assume is sort of the center of this invisible
rectangle.
- This instant-motion of the mouse pointer in a given
direction seemed to be accompanied by a (more or
less) slight shift of the invisible rectangle in the
same direction.
==>Moral: if I wanted to reach an inaccessible point
to the left, I instead tried to reach an inaccessible
point to the right, until the invisible rectangle
enclosed the point I actually wanted to reach...
Tricky, eh?

Further more, I saw that the controlability (see
Moral above) is proportional to the invisible
rectangle size, and I saw that the controlability
varies with the Wine desktop config and with the Wine
patch. Roughly:
- The more advanced Wine is (that is for each new
patch), the more close the invisible rectangle is to
the actual ST screen size.
- Each Wine desktop size "behaves" differently, and
Stew in a window or Stew fullscreen (inside the Wine
Desktop, that is) "behave" differently: the best I
achieved is 800x600 fullscreen (almost OK with last
patch).

It seems that all this is related to the way a
Windows application can take control of the mouse
pointer (is it part of DirectDraw?).
<<<<<
This is now solved. It works fine now.

Does anyone know anything that could help me about
the still unresolved problems?
Thanks!

Yves.

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif