follow-up on previous [HELP] messages

yves-gablin at yves-gablin at
Mon Aug 13 03:05:15 CDT 2001

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
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


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
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
- 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

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?


______________________________________________________________________________, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...

More information about the wine-users mailing list