Dear wine developers,
I have one question on the development of wine. Long(one or
two years) ago I've heard that Microsoft got some hidden
APIs in their products of various windows, and they use
these APIs in their own applications. I wonder if this is
still a problem on their recent product like windows XP. If
it is, I guess wine will not be able to run such MS
applications which uses hidden APIs. Is this right?
And, is wine designed(or its goal is) to run all
applications(including MS product and non-MS product) that
runs on windows?
Please forgive me if this problem has appeared in the
past. I just joined this list a couple of days ago.
Thank you.
Regards,
--
Zhang Shu
Hi,
I am new to Wine develop, I wish to investigate and join, the following
is the topic I am interested in.
Does Wine develpers planning to implement .fon files support? I mean
loading it dynamically? Since Xfree86 4 supports true type fonts, and
most of the Linux distribution are now using XFree86-4 . We can actually
load these fonts into the Xsever dynamically at run time providing we
have some dynamic conversion between the font files.
David
Bug 98 - Unicode, i18n support is quite vague. How could I flesh it
out?
For instance I am thinking that we could convert this into a
metabug and have one sub bug for each control that still needs to
be unicodified. So:
* which are the common controls that still need to be unicodified?
* are there other controls that need to be unicodified
* do common dialogs need work?
As usual the goal is to make the individual tasks more visible so as
to give inspiration to potential contributors, and so that we have a
better idea of our progress and what remains to be done.
Another issue, which would fall more in the i18n part is BiDi
support. What is the scope of this? Does it require modifications of
all the controls like unicode?
http://www.winehq.com/hypermail/wine-devel/2002/03/0236.html
Shachar, it sounds like you started working on this, should I say so
when I create a bugzilla task for this? Even better, can I assign the
task to you? (it can always be reassigned later, it's just a more
flexible way of doing things).
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
Broadcast message : fin du monde dans cinq minutes, repentez vous !
before latest Alexandre patch, CreateProcess was able to use stuff like:
CreateProcess(NULL, "foo.exe --wine_opt -- --foo_opt")
--wine_opt was seen by foo as options for wine, whereas foo_opt could be
a command line option for foo (in foo, the command line would only be
"--foo_opt")
since last night, this is broken:
- --wine_opt is still seen as a wine option
- however, the command line passed to foo isn't cleaned up... we get the
whole line "--wine_opt -- --foo_opt"...
what should we do. I think Alexandre long term option is to really get
rid of the options on the command line and use the WINEOPTION(S) env
var (we could still have a wrapper script to do the conversion)
should we adopt this right away or clean up the command line option ?
as a consequence, you no longer can use any CUI program in the
user/graphical mode, including winedbg - it still work as a unix console
though
A+
Hi,
Running make test with a desktop window
leaves ok but 2 processes are still running
and the desktop windows not closed.
They cannot be closed when I use the cross or the
close command, i must kill them. (don't have to use -9
parameter)
Running processes are :
/home/wine/wine tests/vartest.c
/home/wine/wine tests/sysparams.c
(wineserver is here)
I tried to winedbg them, but got error when I typed
attach : error 5 (ERROR_ACCESS_DENIED).
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Hi!
If I change the window with keyboard (eg with ALT-TAB), then when I switch
back to the wine window wine still thinks that the ALT button is depressed.
I happens, because the key event of pressing ALT arrives to the wine window
before the switch. And I see in the console (with --debugmsg +key) the next
lines:
trace:key:X11DRV_KeyEvent state = 10
trace:key:X11DRV_KeyEvent KeyPress : keysym=FFE9 (Alt_L), ascii chars=0 / 0 /
''
trace:key:X11DRV_KeyEvent keycode 0x40 converted to vkey 0x12
trace:key:X11DRV_KeyEvent bScan = 0x38.
trace:key:queue_kbd_event wParam=0012, lParam=20380001, InputKeyState=81
trace:key:TranslateMessage (WM_SYSKEYDOWN, 0012, 20380001)
trace:key:TranslateMessage Translating key VK_MENU (0012), scancode 38
trace:key:X11DRV_ToUnicode (0012, 2038) : faked state = 10
trace:key:X11DRV_ToUnicode ToUnicode about to return 0 with char bbc6
trace:key:queue_kbd_event wParam=0012, lParam=c0000001, InputKeyState=1
That is the key state has been changed. And when I return to the wine window
(by keyboard or mouse) it acts like if the ALT button were depressed.
The solution is that the key states should be reset when the wine gets back
the focus or loses the focus.
That is more exactly in windows/winpos.c in the function
WINPOS_SetActiveWindow when the hWnd is NULL !
That is the case when switching from a wine window to an non-wine window.
So I have found the place :), just I dont know whats the preferred way to
reset all the key states to not pressed.
I have added the next few lines:
--- oldwinpos.c Fri Mar 29 16:54:59 2002
+++ winpos.c Fri Mar 29 16:55:08 2002
@@ -1217,6 +1217,12 @@
if ((wndPtr = WIN_FindWndPtr(hWnd)))
hWnd = wndPtr->hwndSelf; /* make it a full handle */
+ /* reset key states when switching to a non-wine window */
+ if (hWnd == 0)
+ {
+ InputKeyStateTable[VK_MENU] &= ~0x80;
+ goto CLEANUP_END;
+ }
+
/* paranoid checks */
if( hWnd == GetDesktopWindow() || (bRet = (hWnd == hwndActive)) )
goto CLEANUP_END;
And now my problem is fixed. But I have experienced the same problem with the
Control button (altough it is harder to reproduce). So maybe all the key
states should be reset.
So I would like to have this patch or something similar in wine.
Best regards
Zsolt Rizsanyi
Hi all.
I'm wondering how difficult it is to port an application to Linux with WineLib.
There are quite a few N64 emulators with source code on Windoze and I want to
port one of them to Linux, because there is no decent native emulator, First,
is it possible that things which don't work well with Wine, work when they are
ported using WineLib ? Second, how much work is involved ?
Regards,
--
Boris Buegling <boris(a)icculus.org>
"Sleep less - live longer." - "Ok good, 1 down... Now all I need is beer, video
games and hacking to be linked to living longer and I'm set."
"If it stinks, it's chemistry. If it moves, it's biology. If it does not work,
it's computer science."
The DIB engine was discussed quite a lot at WineConf. I am now trying
to summarize these discussions to update bug 421 - Implement a DIB
engine.
http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=421
Is the following accurate, complete, etc? Comments? Other ideas?
Any volunteers?
This was discussed quite a bit at WineConf. Ideas that were floated
around are:
1. Have X export the required API
---------------------------------
XFree86 4 has all the needed code, for all bit depths and layouts we
care about. We could try to have the X guys export this in the form of
an API ala Xft. Wine could then link with this library to implement the
DIB engine (or dlopen that library).
* Is the needed API already available?
* If not, are the XFree86 guys willing to export it?
* Almost everyone is using XFree86, but what about people who don't
(embedded devices, Wine on Solaris...). We need a fallback.
* We won't have to maintain that code which is a good thing, although
it is not supposed to change much once written.
* Will we be able to do all that we need with that API? Probably yes
since it can be expected to match the X API quite closely and we are
abel to use the X API.
2. Copy the relevant X code into Wine
-------------------------------------
Since X has all the code and that code is under the X11 license we could
copy it all into Wine.
* This means we will have to maintain the code ourselves, although
it is not supposed to change much once written.
3. Copy the relevant code from MicroWindows/NanoGUI to Wine
-----------------------------------------------------------
MicroWindows/NanoGUI also has code that could help us bootstrap our DIB
engine. We probably don't want Wine to depend on these projects but we
could copy their code into Wine.
* Are the licenses compatible?
* Do they support all the bit depths and layouts we care about?
* This means we will have to maintain the code ourselves, although
it is not supposed to change much once written.
4. Copy the relevant code from GGI to Wine
------------------------------------------
GGI also has similar code. Again we probably don't want to
introduce a dependency on GGI so the same questions apply:
* Are the licenses compatible?
* Do they support all the bit depths and layouts we care about?
* This means we will have to maintain the code ourselves, although
it is not supposed to change much once written.
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
"Utilisateur" (nom commun) :
Mot utilisé par les informaticiens en lieu et place d'"idiot".
Hi,
I'm getting this error running a system under WINE:
0806faa8:Call kernel32.CreateFileA(405b63ec
"C:\\WIN\\IY032097.DAT",80000000,00000003,00000000,00000003,08000001,0000000
0) ret=6002912b
0806faa8:trace:file:CreateFileA C:\WIN\IY032097.DAT GENERIC_READ
FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING
0806faa8:trace:dosfs:DOSFS_GetFullName C:\WIN\IY032097.DAT (last=1)
0806faa8:trace:string:lstrcpynA (0x405b5a4c, "/mnt/c", 1024)
0806faa8:trace:dosfs:DOSFS_FindUnixName /mnt/c,WIN\IY032097.DAT
0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00010bfc): returning
403a9e6c
0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00000018): returning
403a7d10
0806faa8:trace:dosfs:DOSFS_FindUnixName (/mnt/c,WIN\IY032097.DAT) -> win
(WIN)
0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a7d10): returning TRUE
0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a9e6c): returning TRUE
0806faa8:trace:dosfs:DOSFS_FindUnixName /mnt/c/win,IY032097.DAT
0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00010bfc): returning
403a9e6c
0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00000018): returning
403a7d10
0806faa8:warn:dosfs:DOSFS_FindUnixName 'IY032097.DAT' not found in
'/mnt/c/win'
0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a7d10): returning TRUE
0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a9e6c): returning TRUE
0806faa8:warn:file:CreateFileA Unable to get full filename from
'C:\WIN\IY032097.DAT' (GLE 2)
.........
08079370:RET MFRTS32.1199: _mFfindp() retval = 409c5e90 ret=0042b3b7
08079370:CALL MFRTS32.1425: mF_fh_set_fe_stat(00000000) ret=0042b3c8
08079370:RET MFRTS32.1425: mF_fh_set_fe_stat() retval = 00000000
ret=0042b3c8
08079370:RET MFRTS32.1202: _mFg2star_fast() retval = 00000000 ret=0042889a
08079370:RET MFRTS32.1400: ixfile() retval = 00000000 ret=60025e45
08079370:RET MFRTS32.145: EXTFH() retval = 00000000 ret=0044095a
08079370:Call user32.MessageBoxA(00000000,004472de "External Path string
<UPCW56-DEV-DATA-DIR> not found. File IYF029. "...,004471c8
"IYP139 ",00002010) ret=00404c01
08079370:warn:dialog:MessageBoxA Messagebox
08079370:trace:resource:RES_FindResource2 (4067a000, 00000005,
40718554"MSGBOX", 0000, A, PE)
08079370:trace:heap:RtlAllocateHeap (40360000,00000002,00000018): returning
403af734
08079370:trace:heap:RtlFreeHeap (40360000,00000002,403af734): returning TRUE
08079370:trace:resource:RES_LoadResource (4067a000, 407234f8, PE)
.........
Seems like the file isn't being created. (Uwe Bonnes helped me with this).
But we disagree what part of WINE (or outside WINE) is wrong.
The first part of the log shows a CreateFileA that is unable to create a
file.
This API works fine when the file is in the same dir as the application (had
tested it).
The second part of the log shows the last screen I get after start the
program (MessageBox API).
MFRTS32 is a .dll the program calls. We thougth of there too.
But this program works under Windows. Everything is in the path. Both
wine.conf and Linux.
I could reproduce the error in Win2k this way:
Created a set of programs (L1, L2 and L3) that will run one after one with
conditions. If the field in L1 is fulfilled then we jump directly to L3.
Else We fulfill the field in L2 and then jump to L3.
In details: L1 would creates a file with a name if the filed is fulfilled an
L3
NEEDS to know that name.
If we had to run L2 then the file will be with another name
and L3 will get data from that file.
But the file ins't created in neither of the cases. So a screen shows up:
"External path string <G-PATH> not found. File FILE-LINUX."
That message is the same I get under WINE:
"External path string <UPCW56-DEV-DATA-DIR> not found. File IYF029."
Refers to a file (IYF029), that exists (located in the ./data dir)
but was not filled with data it need to work, or incorretly filled.
Both G-PATH and UPCW56-DEV-DATA-DIR are variables of a file that has a
number
of them inside.
As here we use APIs I'll list 2 of them that are used within the function
and
their definiton, took from MSDN:
CreateProcess
CreateProcess(
LPCWSTR lpszImageName,
LPCWSTR lpszCmdLine,
LPSECURITY_ATTRIBUTES lpsaProcess,
LPSECURITY_ATTRIBUTES lpsaThread,
BOOL fInheritHandles,
DWORD fdwCreate,
LPVOID lpvEnvironment,
LPWSTR lpszCurDir,
LPSTARTUPINFOW lpsiStartInfo,
LPPROCESS_INFORMATION lppiProcInfo);
........
StartupInfo.dwFillAttribute
dwFillAttribute
Ignored unless dwFlags specifies STARTF_USEFILLATTRIBUTE.
Specifies the initial text and background colors if a new console window is
created in a console application. These values are ignored in GUI
applications.
This value can be any combination of the following values:
FOREGROUND_BLUE, FOREGROUND_GREEN, FOREGROUND_RED, FOREGROUND_INTENSITY,
BACKGROUND_BLUE, BACKGROUND_GREEN, BACKGROUND_RED, and BACKGROUND_INTENSITY.
For example, the following combination of values produces red text on a
white
background:
FOREGROUND_RED| BACKGROUND_RED| BACKGROUND_GREEN| BACKGROUND_BLUE
OBS.: We do NOT use this to send this kind of attributes.
We DO send more data as we saw that it handles well.
We also DO use this in gui applications.
typedef struct _STARTUPINFO {
DWORD cb;
LPTSTR lpReserved;
LPTSTR lpDesktop;
LPTSTR lpTitle;
DWORD dwX;
DWORD dwY;
DWORD dwXSize;
DWORD dwYSize;
DWORD dwXCountChars;
DWORD dwYCountChars;
DWORD dwFillAttribute;
DWORD dwFlags;
WORD wShowWindow;
WORD cbReserved2;
LPBYTE lpReserved2;
HANDLE hStdInput;
HANDLE hStdOutput;
HANDLE hStdError;
} STARTUPINFO, *LPSTARTUPINFO;
...............
CreateFile
HANDLE CreateFile(
LPCTSTR lpFileName, // file name
DWORD dwDesiredAccess, // access mode
DWORD dwShareMode, // share mode
LPSECURITY_ATTRIBUTES lpSecurityAttributes, // SD
DWORD dwCreationDisposition, // how to create
DWORD dwFlagsAndAttributes, // file attributes
HANDLE hTemplateFile // handle to template file
);
..................
Any thoughs?
Thanks,
Ricardo.
I know regression testing isn't as interesting as
doing real development, and so I appologize with once
again spamming the list with regression questions...
As I've been writing tests (only for the last
week or so), I realized that as we get a lot more tests,
it will be very difficult to keep track of what is being
tested, and what is not. I'd like to propose a list of
which functions for each DLL are being tested, which file
tests it, as well as any comments on the current tests.
Currently, there is no great way to do this. I
may use several functions in a directed test which I am
not actually testing (for instance I've found it
necessary to retrieve the page-size using GetSystemInfo,
but my tests have nothing to do with this function, and
so writing a directed test for it is a task for another
day). Thus just grepping for which functions are used in
a test is not sufficient.
Also, I have found that some functions, or even
specific task functions are very difficult to test, and
so I've been leaving these out so that perhaps people ore
skilled than myself could take a crack at them late (A
good example is testing inheritance with CreateThread.
It is a task that is beyond my capabilities at the
moment, at least until I can find a good way to test
CreateProcess...this would be much easier if Windows had
something equivalent to 'fork'). In any case, I've tried
to be thorough about commenting what I do and don't test,
but it would be a lot more convenient if this information
was more easily parsed than trying to find my comments
intersperesed through the tests.
So does anyone thing that creating a easily
parsable list with the state of the current tests is this
a reasonable thing to do, and would creating a simple
file in each /tests directory with the information be
good enough? If so, I can add one to my next test, and
update it with what I've done so far.
In general, while Francois' presentation is a
good place to get started, I think it'd be a lot easier
if there was a document off of winehq with
recommendations on how to build, test, and document
tests. Lowering the difficulty threshold, is more likely
to draw more people to do so.
Thanks,
.Geoff
