January 2003 - Wine-Devel - list.winehq.org

Re: patch for "GetFileTitleW: illegal call to GetFileTitleA" 2ed

by Alexandre Julliard

liu spider <liuspider(a)yahoo.com> writes: > short WINAPI GetFileTitleA(LPCSTR lpFile, LPSTR lpTitle, UINT cbBuf) > { > - int i, len; > + int ret; > + UNICODE_STRING strWFile, strWTitle; > + RtlCreateUnicodeStringFromAsciiz(&strWFile, lpFile); > + RtlCreateUnicodeStringFromAsciiz(&strWTitle,lpTitle); > + ret = GetFileTitleW(strWFile.Buffer, strWTitle.Buffer, cbBuf * sizeof(WCHAR)); lpTitle is an output parameter, you can't convert it to Unicode on input, you should allocate a buffer instead. -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2003

Re: new to wine and would like to be actively involved.

by Shravan Sadasivan

Sorry about my previous email people... I just realized I should have said virtual "wine" and not beer.. Told you I would be ignorant in the beginning ;) Shravan At 11:22 PM 1/13/2003 -0800, Dan Kegel wrote: >Tom Wickline wrote: >>> I am new to the wine developement community and would like to actively >>>get involved in the activities in this community. Could anyone please >>>educate me on how i can go about doing that?.. I have strong developement >>>skills in C and Perl.. and have worked with converting C source code in >>>informix. Awaiting more from your side.. >>Here is a starter guide :) I'm sure there is alot of other goodies to >>work on as well. >>See : http://www.dssd.ca/wine/Wine-Contrib-0.7.html > >I strongly recommend adding to the conformance test suite >as a first step for people with strong C skills! > >By the way, >http://www.dssd.ca/wine/Wine-Contrib-0.7.html#conf_tests >still says >"Either C or perl skills" >but perhaps this should just say >"C programming skills" >as the Perl tests were removed. >- Dan > >-- >Dan Kegel >http://www.kegel.com >http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 >

Jan. 14, 2003

Re: new to wine and would like to be actively involved.

by Shravan Sadasivan

Hi Team, A big thank you to all you guys for the warm welcome and the tips. I will get down to following your suggestions actively and you will see me taking part in discussions as well as coming up with suggestions for the betterment of wine. Please bear with me in case I am a little ignorant towards the beginning :) .. otherwise virtual beer's to one and all on this list. Shravan At 05:20 PM 1/13/2003 -0500, Dimitrie O. Paun wrote: >On January 13, 2003 02:09 pm, Shravan Sadasivan wrote: > > I have strong developement > > skills in C and Perl.. and have worked with converting C source code in > > informix. Awaiting more from your side.. > >Hi Shravan, > >There are plenty of things to do, you will find some of them >on these pages: > http://www.dssd.ca/wine/ > >Check out the Fun/Janitorial/Winelib/0.9 TODO/Contrib pages. > >Welcome to the team! > >-- >Dimi. > >P.S. I hope you know we can not accept contributions unless they > have been conceived while under the influence of at _least_ > 3-5 glasses of (good) wine... :)

Jan. 14, 2003

Re: Help wanted: Implementing Wine dlls that need access to X11 commands.

by Alexandre Julliard

Robert North <7ownq0k402(a)sneakemail.com> writes: > But note that this would reqire some patching to the x11drv > dll to do the following > 1. decode the messages. > 2. enable the messages for a given window and display. > But I'm assuming that changing the x11drv code could cause > severe regressions to wine. > I'm therefore assuming that it's good manners to avoid > fiddling with x11drv code till the > wintab driver implementation is known to be adequate. I don't think it would necessarily cause regressions to simply add handling for new events, since it shouldn't require changing the existing event handling. But anyway writing a separate prototype first is certainly a good idea. > Now, as it turns out, the methods to interrogate a wintab > message queue are extremely similar to those to interrogate an X11 > message queue. > So that's +1 to giving wintab it's own X11 message > queue. (Or possibly even one X11 msg queue per tablet context!). > A simple X11<->wintab mapping can be implemented, and no > additional queue data structs are needed in the wintab > implementation. I'm not convinced you can avoid managing an event queue for wintab events; from a quick look at the spec I doubt you can simply map the wintab functions to X11 queue functions. > I think after all that complexity, that's +4 or more to > X11 message queue implementation, and for wintab at least, avoid the > wine message queue. I agree you probably don't want to store wintab events in the Windows message queue. But that doesn't mean you have to create your own X connection and event loop, you can simply retrieve the events from the normal X event loop and store them into the wintab queue. -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2003

Winedbg: Open Xterm when Controlling console no more available

by Uwe Bonnes

Hallo Eric, another winedbg feature request: When the starting application spawns off other processes and exec itself, with the other spawned processes still running, and one of these processes crashes, and winedbg is configured to work on the starting console, winedbg starts, loads all dll, but then exits immediate due to the missing console. In this situation, winedbg should test if console access is still possible, and when not, it should start magically an xterm. I still prefer to use the console for winedbg interaction, as scrolling is easier. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 14, 2003

Re: Wine and Windows error code

by Dan Kegel

mpfbk(a)free.fr wrote: > While looking inside the wine sources, it appears that no error code is set in > the functions 'CreateWindowExA' in windows/win.c file when the window's class is > not found Sounds like a good bug. While the manual test you wrote looks useful for exploring, could you please convert it to a compliance test and send it in as a patch before you fix the bug? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 14, 2003

Re: problem building tests with msvc6

by Paul Millar

On Tue, 14 Jan 2003, Dan Kegel wrote: > *oh*. Your page should say that clearly, then, and should also > mention what real operating system you're running on. Yep, looking at the wording it is a little vague. I'll update the page with better chosen words in a mo. > Could your scripts be used to automate building or running > the wine tests under real Windows (perhaps with the help of > cygwin and msvc6)? Well, I've been trying to get mingw to work. Once that's up and going it should be _fairly_ straight forward to add real Windows testing. (famous last words ;) ---- Paul Millar

Jan. 14, 2003

Re: problem building tests with msvc6

by Paul Millar

On Tue, 14 Jan 2003, Francois Gouget wrote: > On Mon, 13 Jan 2003, Dan Kegel wrote: > [...] > > Also, *what tests* are you running on those versions > > of ms-windows? AFAIK, all our tests are win32... Sorry, I missed that bit. Nope, none of the tests are running on a Windows platform at the moment, they're all running on Wine. > That also had me confused for a while. In fact none of the tests are > running on Windows. They are all running on Wine and Wine is told to > emulate Win95, Win98, etc. Yes, they're all running on Wine. The original idea was to run a set of tests (at the moment, just the conformance tests) every time CVS changes. That way problems are spotted as soon as they happen. When Francois discovered that the conformance tests aren't actually testing real Windows behaviour I figured there was another, deeper problem: not so much fixing the broken tests but keeping them fixed. I've been working on adding that functionality to WRT so that it also checks the tests on various Windows platforms every time the tests change. I'm currently having trouble building the MinGW-cross compiler, but hopefully once that's fixed I should be able to get things going :) > It's not that it not useful, it is. It's just that at first I hoped it > was running the tests on the real thing and reported the results. But I > guess that was a bit unrealistic. With a bit of luck the tests should be up "soon". ---- Paul Millar

Jan. 14, 2003

Wine and Windows error code

by mpfbk＠free.fr

Tests of win32 API returned error codes inside Wine This subject has maybe been treated before, sorry if it has already been discussed and closed. Running the following simple and standard program, nothing special happens: the windows opens itself, it can be closed with the close button, and the message box is displayed when the left mouse button is pressed inside the window. /* * testbed1_ref.c * */ #define STRICT #include <windows.h> const char g_szClassName[] = "testbed1WindowClass"; /* ============================================================ */ static void ErrorBox(LPCSTR msg) { LPVOID error_msg; DWORD error_code; char error_buffer[256]; error_code = GetLastError(); FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, NULL, error_code, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR) &error_msg, 0, NULL ); /* TBC: should be snprintf */ sprintf(error_buffer, "%s: %d:%s", msg, error_code, error_msg); MessageBox(NULL, error_buffer, "Error!", MB_ICONEXCLAMATION | MB_OK); LocalFree( error_msg ); } /* ============================================================ */ LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch(msg) { case WM_LBUTTONDOWN: { char szFileName[MAX_PATH]; HINSTANCE hInstance; if(IsDebuggerPresent()) { MessageBox(NULL, "Running under debugger control", "Debug!", MB_ICONINFORMATION | MB_OK); } else { OutputDebugString(TEXT("No debugger, but 'OutputDebugString' works, since you see this (in DBWin32 for instance)")); } hInstance = GetModuleHandle(NULL); GetModuleFileName(hInstance, szFileName, MAX_PATH); MessageBox(hwnd, szFileName, "This program is:", MB_OK | MB_ICONINFORMATION); } break; case WM_CLOSE: DestroyWindow(hwnd); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hwnd, msg, wParam, lParam); } return 0; } /* ============================================================ */ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASSEX wc; HWND hwnd; MSG Msg; /* Register the Window Class */ wc.cbSize = sizeof(WNDCLASSEX); wc.style = 0; wc.lpfnWndProc = WndProc; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = LoadIcon(NULL, IDI_APPLICATION); wc.hCursor = LoadCursor(NULL, IDC_ARROW); wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); wc.lpszMenuName = NULL; wc.lpszClassName = g_szClassName; wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION); if(!RegisterClassEx(&wc)) { ErrorBox("Window Class Registration Failed!"); return 0; } /* Create the Window */ hwnd = CreateWindowEx(WS_EX_CLIENTEDGE, g_szClassName, "The title of my window", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 240, 120, NULL, NULL, hInstance, NULL); if(hwnd == NULL) { ErrorBox("Window Creation Failed"); return 0; } ShowWindow(hwnd, nCmdShow); UpdateWindow(hwnd); /* Run Message Loop */ while(GetMessage(&Msg, NULL, 0, 0) > 0) { TranslateMessage(&Msg); DispatchMessage(&Msg); } return Msg.wParam; } What is a little bit unusual is the ErrorBox function : often, a message box simply reports the error and aborts the program. ErrorBox uses GetLastError() and FormatMessage() to provide somewhat more information. By accident, let's make an error, commenting out the RegisterClassEx() call : #if 0 if(!RegisterClassEx(&wc)) { ErrorBox("Window Class Registration Failed!"); return 0; } #endif Under Windows (tested with NT4 and XP), the displayed message (by ErrorBox) is: == Window Creation Failed: 1407: Can't find window class == But, under wine (20021219), the displayed message is, unfortunately : == Window Creation Failed: 0: No error == While looking inside the wine sources, it appears that no error code is set in the functions 'CreateWindowExA' in windows/win.c file when the window's class is not found : an error message is printed and 0 is returned. The following adds the appropriate error code in function CreateWindowExA : around line 1291 and 1301: SetLastError(ERROR_CANNOT_FIND_WND_CLASS); before the return 0; Questions : does it have any interest for wine to add these error codes ? If yes, according to DLL separation, is it allowed to call SetLastError() in any context ? Should I submit a patch ? Any other feedback ?

Jan. 14, 2003

Re: Problem with interrupt vector

by Gustavo Junior Alves

Sorry about the long delay.... Try an already installed Windows version, then call from Wine. I believe this will works.. Gustavo Sylvain Petreolle wrote: >tried to install it, says "corrupt installation detected". > --- Gustavo Junior Alves <alves(a)coslinux.com.br> a écrit : > Is a >goverment program for incoming taxes. Appear to be made in > > >>Delphi. >> >>The log from app (wine --debugmsg +int) is: >> >>err:ntdll:RtlpWaitForCriticalSextion section 0x400f3ac8 >>"../../scheduler/syslevel.c: Win16Mutex" wait timed out, retrying (60 >> >>sec) tid=08074ff8 >>trace:int:WIN87_fpmath (cs:eip=42f:1155 es=23f bx=0000 ax=0000 >>dx==0002) >>trace:int:WIN87_fpmath (cs:eip=42f:1163 es=23f bx=0003 ax=1168 >>dx==042f) >>fixme:toolhelp:InterruptRegister16 (0000, 0x24700ba), stub. >>wine: Unhandled exception, starting debugger... >> >> > > >===== >Sylvain Petreolle >spetreolle(a)users.sourceforge.net >Fight against Spam ! http://www.euro.cauce.org/en/index.html >ICQ #170597259 > >"Don't think you are. Know you are." Morpheus in Matrix, chapter 15. > >___________________________________________________________ >Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! >Yahoo! Mail : http://fr.mail.yahoo.com > >

Jan. 14, 2003