- Wine-Devel - list.winehq.org

CreateProcessA and winboard
by erwin wolff Sept. 15, 2003

Sept. 15, 2003

Hey everyone, I think I got the reason why winlib's winboard doesn't work. The createprocessa function doesn't work on either the winlib compiled version or the native version. Although the winelib version of winboard works better than the windows version. This is the output I got from the windows version: fixme:process:CreateProcessA (C:\winboard\GNUChess.exe,...): CREATE_NEW_PROCESS_GROUP ignored fixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yet It fired up GNUchess.exe and openend it in a window, but then it crashed >:(. The winelib counterpart gave me a more useful debug report: fixme:gdi:ExtCreatePen Hatches not implemented fixme:gdi:ExtCreatePen Hatches not implemented fixme:gdi:ExtCreatePen Hatches not implemented .... fixme:process:CreateProcessA (C:\winboard\GNUChess.exe,...): CREATE_NEW_PROCESS_GROUP ignored fixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yet If you need the patch to compile and can't find it in the mail listing, just contact me :). I hope someone can fix it.

1 0

List of API functions and completeness.
by Jacobus Erasmus Sept. 15, 2003

Sept. 15, 2003

Hi I'm looking for a list of all the functions that would be displayed in a debug list. I'm feel like doing a fun project and am wondering if any body have pointers on how I can obtain the information I need. Basically I'm interested in writing a little script that would run through a debug output and pickup all the functions called with the execution of the Windows program in wine. I then want to match the functions called with a DB that tell me what the estimated completion level of each function is. The idea is to then is to calculate the probability that a program will function correctly with the current wine implementation. This is done using statistical data and estimation data for each function. (Like I say just for interest sake). What bothers me is the estimation of function completeness. How can I measure or alternatively collect this. Any suggestions would be appreciated. -- Jacobus Erasmus <jacobus(a)kewlconcepts.co.za> Kewlconcepts

2 1

Re: Taskmanger Relicense: Was Unable to cimpile wineproc
by thomas.mertes＠gmx.at Sept. 15, 2003

Sept. 15, 2003

Eric Pouech (pouech-eric_at_wanadoo.fr) wrote: > + Don't depend on msvcrt > - added wine only dumb macros for _ui64toa and _ultoa This is not necessary _ui64toa and _ultoa are defined in the ntdll. See ntdll.spec: @ cdecl _ui64toa(long long ptr long) @ cdecl _ultoa(long ptr long) and ntdll/string.c: char * __cdecl _ui64toa( ULONGLONG value, /* [I] Value to be converted */ char *str, /* [O] Destination for the converted value */ int radix) /* [I] Number base for conversion */ ...... char * __cdecl _ultoa( unsigned long value, /* [I] Value to be converted */ char *str, /* [O] Destination for the converted value */ int radix) /* [I] Number base for conversion */ ...... May be prototypes of _ui64toa and _ultoa should be added to winternl.h or some other ntdll specific include file. In the moment this prototypes are only defined in msvcrt/stdlib.h: char* _ui64toa(unsigned __int64,char*,int); char* _ultoa(unsigned long,char*,int); Greetings Thomas Mertes -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post

1 0

Re: Link winlib with windows DLL help????
by Fabian Cenedese Sept. 15, 2003

Sept. 15, 2003

>I try "winemaker -iavisynth_c ." >But when making I get "could not open .def file for avisynth_c" > >And I am not sure how to create this .def file. Quite easy. It's a simple text file filled with the exported functions like DESCRIPTION 'My Special DLL' EXPORTS CMRegisterControl @1 CMUnregisterControl @2 CMGetCommandString @3 CMRegisterCommand @4 etc. I'm sure you will find more info about this on the net. bye Fabi

1 0

Regedit
by Ivan Leo Murray-Smith Sept. 15, 2003

Sept. 15, 2003

Hi list, I'm translating regedit to italian, and I wanted to make it as similar as possible to the windows regedit. The only problem is that the wine regedit is based on the english m$ regedit, but m$ has written the italian version in a slightly different way. For example, what in the m$ english version and in the wine version is import registry file in the m$ italian version is translated into import file of the configuration registry Now I'm not sure if I should base the italian translation of the wine registry on the english version of the registry(I suppose it would be more consistent with other translations), or if I should translate it as m$ has done(What I think is best, as any user coming from an italian windows installation would find familiar menus), any advice would be greatly appreciated.

2 1

keyboard broken in DOS (real mode)
by Michael Stefaniuc Sept. 14, 2003

Sept. 14, 2003

Hello, the installer of the free IDA pro version (http://www.simtel.com/pub/pd/27629.html) dosn't work with wine due missing keyboard input. Pressing some keys makes wine to spit out following error: err:int:DOSVM_Int09SendScan keyboard queue overflow The emulated hardware keyboard buffer overflows because the keys don't make it to the emulated BIOS keyboard buffer. DOSVM_Int09SendScan queues an event for IRQ1 but no handler for int 09 is ever called (the int 09 handler copies the keys from the hardware to the BIOS keyboard buffer). (Thx to Ove for the explanation how things should work) >From the +int,+int21,+relay debug output it seems like the event queued by DOSVM_Int09SendScan is stuck in the queue. I had a look at DOSVM_QueueEvent and the other dosvm and interrupt functions but i didn't see the light of how this stuff works and why the queued event is never processed. Some help with that would be grateful. Btw the keyboard input seems to work in protected mode (tested with the setup program of Imperium Romanum using the DOS32A extender). bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

load library problem
by Dimitrie O. Paun Sept. 14, 2003

Sept. 14, 2003

Hi folks, I have flagged this before, but got no answer. Once again, this a C++ Winelib app (one of the wxWindows samples): [dimi(a)dimi calendar]$ ls calendar* calendar calendar_calendar.o calendar.cpp calendar.exe.so calendar.o calendar.rc calendar-wrap.dll.so calendar.bkl calendar_calendar_rc.o calendar.dsp calendarM5.xml calendar.pro calendar_resources.o [dimi(a)dimi calendar]$ export WINEDLLPATH=`pwd` [dimi(a)dimi calendar]$ echo $WINEDLLPATH /home/dimi/dev/wine/wxWindows/samples/calendar [dimi(a)dimi calendar]$ wine --debugmsg +module,+loaddll calendar.exe.so 2>log [dimi(a)dimi calendar]$ tail log trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\calendar\\calendar.exe" trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\calendar\\calendar.exe" trace:module:MODULE_GetLoadOrder looking for C:\WINDOWS\SYSTEM\calendar-wrap.dll trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\calendar\\calendar.exe" trace:module:open_app_key searching 'calendar-wrap' in AppDefaults\calendar.exe\DllOverrides trace:module:MODULE_GetLoadOrder got standard wildcard "b,n" for "calendar-wrap.dll" trace:module:load_dll Trying built-in 'C:\WINDOWS\SYSTEM\calendar-wrap.dll' trace:module:load_dll Trying native dll 'C:\WINDOWS\SYSTEM\calendar-wrap.dll' warn:module:load_dll Failed to load module 'C:\WINDOWS\SYSTEM\calendar-wrap.dll'; status=c000000f Error: Could not load the application's module calendar-wrap.dll (126) The piece of code that fails is from the automatically generated wrapper[1]. Here is the part that fails: LoadLibrary("calendar-wrap.dll"); I have the WINEDLLPATH set, what gives? Alexandre, I can't really track this easily back, but I have a gut feeling it got triggered by one of the reorganizations that you did around the loader... [1] That is how the app was linked: [dimi(a)dimi calendar]$ winewrap -v -k -mgui -C -o calendar.exe calendar_calendar.o calendar_calendar_rc.o -L../../lib -lwx_msw-2.5 -lwxexpat -lz -lrpcrt4 -loleaut32 -lole32 -lwine_uuid -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 -lpng -ljpeg -ltiff -lcomdlg32 -ladvapi32 -lshell32 Creating file /tmp/wapp9rVK4g.spec winebuild -o /tmp/wapp9rVK4g.spec.c -F calendar-wrap.dll --spec /tmp/wapp9rVK4g.spec -L/usr/local/lib/wine -L../../lib -lrpcrt4 -loleaut32 -lole32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lgdi32 -luser32 -lkernel32 calendar_calendar.o calendar_calendar_rc.o ../../lib/libwx_msw-2.5.a ../../lib/libwxexpat.a /usr/lib/libz.a /usr/local/lib/libwine_uuid.a ../../lib/libpng.a ../../lib/libjpeg.a ../../lib/libtiff.a gcc -fPIC -o /tmp/wapp9rVK4g.spec.o -c /tmp/wapp9rVK4g.spec.c g++ -shared -Wl,-Bsymbolic,-z,defs -lwine -lm -L/usr/local/lib/wine -L../../lib -o calendar-wrap.dll.so /tmp/wapp9rVK4g.spec.o calendar_calendar.o ../../lib/libwx_msw-2.5.a ../../lib/libwxexpat.a /usr/lib/libz.a /usr/local/lib/libwine_uuid.a ../../lib/libpng.a ../../lib/libjpeg.a ../../lib/libtiff.a Creating file /tmp/wwrpBOB32M.c gcc -fPIC -I/usr/local/include/wine/windows -o /tmp/wwrpBOB32M.o -c /tmp/wwrpBOB32M.c winebuild -o /tmp/wwrpBOB32M.spec.c --exe calendar.exe -mgui /tmp/wwrpBOB32M.o -L/usr/local/lib/wine -L../../lib -lrpcrt4 -loleaut32 -lole32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lgdi32 -luser32 -lkernel32 gcc -fPIC -o /tmp/wwrpBOB32M.spec.o -c /tmp/wwrpBOB32M.spec.c g++ -shared -Wl,-Bsymbolic,-z,defs -lwine -ldl -o calendar.exe.so /tmp/wwrpBOB32M.spec.o /tmp/wwrpBOB32M.o Creating file calendar [dimi(a)dimi calendar]$ cat /tmp/wapp9rVK4g.spec @ stdcall WinMain(ptr long ptr long) WinMain [dimi(a)dimi calendar]$ cat /tmp/wwrpBOB32M.c /* * Copyright 2000 Francois Gouget <fgouget(a)codeweavers.com> for CodeWeavers * Copyright 2002 Dimitrie O. Paun <dpaun(a)rogers.com> */ #include <stdio.h> #include <windows.h> /* * Describe the wrapped application */ /* The app name */ #define APPNAME "calendar" /** * This is either 0 for a console based application or * 1 for a regular windows application. */ #define GUIEXE 1 /** * This is the name of the library containing the application, * e.g. 'hello-wrap.dll' if the application is called 'hello.exe'. */ static char* appName = APPNAME "-wrap.dll"; /** * This is the name of the application's Windows module. If left NULL * then appName is used. */ static char* appModule = NULL; /** * This is the application's entry point. This is usually 'WinMain' for a * gui app and 'main' for a console application. */ #if GUIEXE static char* appInit = "WinMain"; #else static char* appInit = "main"; #endif /** * This is either non-NULL for MFC-based applications and is the name of the * MFC's module. This is the module in which we will take the 'WinMain' * function. */ static char* mfcModule = NULL; void error(const char *format, ...) { va_list ap; char msg[4096]; va_start(ap, format); vsnprintf(msg, sizeof(msg), format, ap); fprintf(stderr, "Error: %s\n", msg); /*MessageBox(NULL, msg, "Error", MB_OK);*/ va_end(ap); exit(1); } #if GUIEXE typedef int WINAPI (*WinMainFunc)(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow); #else typedef int WINAPI (*MainFunc)(int argc, char** argv, char** envp); #endif #if GUIEXE int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) #else int WINAPI main(int argc, char** argv, char** envp) #endif { HINSTANCE hApp = 0, hMFC = 0, hMain = 0; void* appMain; int retcode; /* Then if this application is MFC based, load the MFC module */ if (mfcModule) { hMFC = LoadLibrary(mfcModule); if (!hMFC) error("Could not load the MFC module %s (%d)", mfcModule, GetLastError()); /* For MFC apps, WinMain is in the MFC library */ hMain = hMFC; } /* Load the application's module */ if (!appModule) appModule = appName; hApp = LoadLibrary(appModule); if (!hApp) error("Could not load the application's module %s (%d)", appModule, GetLastError()); if (!hMain) hMain = hApp; /* Get the address of the application's entry point */ appMain = GetProcAddress(hMain, appInit); if (!appMain) error("Could not get the address of %s (%d)", appInit, GetLastError()); /* And finally invoke the application's entry point */ #if GUIEXE retcode = (*((WinMainFunc)appMain))(hApp, hPrevInstance, szCmdLine, iCmdShow); #else retcode = (*((MainFunc)appMain))(argc, argv, envp); #endif /* Cleanup and done */ FreeLibrary(hApp); FreeLibrary(hMFC); return retcode; } -- Dimi.

4 8

Re: [comctl32] Fix listview item activate
by Dimitrie O. Paun Sept. 14, 2003

Sept. 14, 2003

On September 14, 2003 09:36 am, Maxime Bellengé wrote: > + nmia.uNewState = 0; > + nmia.uOldState = 0; > + nmia.uChanged = 0; > + nmia.lParam = 0; > + nmia.uKeyFlags = 0; What about these flags, shouldn't we fill these in as well? At the very least we need an entry in the TODO list at the top of the file... -- Dimi.

1 0

Link winlib with windows DLL help????
by Kevin Atkinson Sept. 14, 2003

Sept. 14, 2003

I am having a hell of a time getting a simple program to link with a windows dll. I am really sorry for the newbie question but I can't seam to find an answer anywhere and the mailing list archive is not searchable. Here is what I got: avs2yuv4mpeg.cpp - the main program avisynth_c.h - header for DLL I need to link with avisynth_c.lib - lib " " " And I want to compile this into an executable avs2yuv4mpeg I try "winemaker -iavisynth_c ." But when making I get "could not open .def file for avisynth_c" And I am not sure how to create this .def file. Please help. Once again really sorry. But the mailing list is not searchable AND the winlib docs are really confusing and do not specially cover this situation. -- http://kevin.atkinson.dhs.org

3 8

Re: wineproc: a new wine utility
by Dimitrie O. Paun Sept. 14, 2003

Sept. 14, 2003

On September 3, 2003 03:53 pm, Eric Pouech wrote: > any comment welcomed!! Sorry for the late reply -- I just got a chance to look into it. It looks good, I hope to see (some version of) it in the tree soon. One thing that bug me were the refreshes -- too much flicker, loss of selection etc. I think we need to be smarter and not change the display if nothing changed. But of course, this can happen once we have something integrated into the tree... -- Dimi.

1 0