November 2002 - Wine-Devel - list.winehq.org

Wine bug-testing methodologies
by Saravanakumar Soundarrajan Nov. 26, 2002

Nov. 26, 2002

Sorry If I am going off the topic, I am a user of wine and I am looking for some information about it. I am doing a research paper on Open Source Software Quality how OSS quality is maintained and Wine is one of topics of discussion. I have been looking for some information on how Wine Bug Testing is done and the methodologies used in Testing Wine(something like how whitebox testing, regression testing, path-testing, etc., are done). I was wondering if anybody knows any website or any information where I can find more on this topic. It will be very helpful for my research. Thanks and Regards, SK. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

1 0

wine and asyncronous file i/o
by Martin Fuchs Nov. 26, 2002

Nov. 26, 2002

Hi! I've got an application, which uses an asynchron file stream library. I uses ReadFileEx() and alertable wait with SleepEx(). This doesn't work right with wine. It seems to get caught in an endless loop. Wine and wineserver together use 100 % cpu power. Does anyone already know, what's going wrong here? I had a quick look at the implementation in wine, but couldn't find any hint about missing functionality or some thing like this. Which debug switches wold be usefull to trace this? -- Martin Fuchs martin-fuchs(a)gmx.net

4 16

Fix for a warning in hal.c
by Vincent Béron Nov. 26, 2002

Nov. 26, 2002

Changelog: Fix for incompatible pointer type in hal.c. Vincent

1 0

Fix for a warning in time.c
by Vincent Béron Nov. 26, 2002

Nov. 26, 2002

Changelog: Fix for implicit declaration of abs. Vincent

1 0

Fix for a warning in xrender.c
by Vincent Béron Nov. 26, 2002

Nov. 26, 2002

Changelog: Fix for deprecated use of label at the end of compound statement in xrender.c. Vincent

1 0

Working with GDI+
by François-Denis Gonthier Nov. 26, 2002

Nov. 26, 2002

Having to port System.Windows.Forms and System.Drawing to Linux, I would like to know how GDI+ works under Wine and WineLib? Anyone tried?

1 0

Winelib Applications
by Dimitrie O. Paun Nov. 26, 2002

Nov. 26, 2002

Folks, A new page has appeared in the Wine constellation <g>. It is still a work in progress, but I hope to release version 0.1 in the next few days, once I have a change to add what I've done on PuTTY, and Visual-MinGW. Check it out: http://www.dssd.ca/wine/Winelib-Apps.html Comments, suggestions, flames -- all welcome! -- Dimi.

3 6

self-registerable COM server dlls
by John K. Hohm Nov. 26, 2002

Nov. 26, 2002

I believe I have a workable method for defining the registration data needed to register and unregister self-registerable COM server dlls like ole32 et. al. that is easy enough to maintain and reasonably efficient. The only real objection I can anticipate is that I use char's instead of WCHAR's, and my reason is that the infrequency of use of these functions makes ease of maintenance more important than performance. I have attached (hopefully as text/plain) the header for the regsvr helper, and the comcat_main.c to give a feel for usage. Comments, please? /* * self-registerable dll helper functions * * Copyright (C) 2002 John K. Hohm * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* regsvr_register and regsvr_unregister take a pointer to registration data. The format of that data is as such (in RFC2234 ABNF): reg_data := LWSP "[" *"!" predef_key "\0" [ "=" value "\0" ] *sub_data "]" ; ! means delete (recursively) when unregistering sub_data := key_data / value_data key_data := LWSP "[" *"!" key "\0" [ "=" value "\0" ] *sub_data "]" ; ! means delete (recursively) when unregistering value_data := LWSP *"!" value_name "\0" "=" value "\0" ; ! means delete when unregistering predef_key := "HKCR" ; others could be added as necessary key := +CHAR value_name := +CHAR value := +CHAR */ HRESULT regsvr_register(char const *data); HRESULT regsvr_unregister(char const *data); /* * exported dll functions for comcat.dll * * Copyright (C) 2002 John K. Hohm * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "comcat.h" #include "regsvr.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(ole); DWORD dll_ref = 0; HINSTANCE COMCAT_hInstance = 0; /*********************************************************************** * Global string constant definitions */ const WCHAR clsid_keyname[6] = { 'C', 'L', 'S', 'I', 'D', 0 }; /*********************************************************************** * Registration data */ static char const regsvr_data[] = "[HKCR\0 [CLSID\0 [!{0002E005-0000-0000-C000-000000000046}\0=StdComponentCategoriesMgr\0 [InProcServer32\0=comcat.dll\0 ThreadingModel\0=Both\0 ] ] ] ]"; /*********************************************************************** * DllMain */ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID fImpLoad) { TRACE("%p 0x%lx %p\n", hinstDLL, fdwReason, fImpLoad); switch(fdwReason) { case DLL_PROCESS_ATTACH: COMCAT_hInstance = hinstDLL; break; case DLL_PROCESS_DETACH: COMCAT_hInstance = 0; break; } return TRUE; } /*********************************************************************** * DllGetClassObject (COMCAT.@) */ HRESULT WINAPI COMCAT_DllGetClassObject(REFCLSID rclsid, REFIID iid, LPVOID *ppv) { *ppv = NULL; if (IsEqualGUID(rclsid, &CLSID_StdComponentCategoriesMgr)) { return IClassFactory_QueryInterface((LPCLASSFACTORY)&COMCAT_ClassFactory, iid, ppv); } FIXME("\n\tCLSID:\t%s,\n\tIID:\t%s\n",debugstr_guid(rclsid),debugstr_guid(iid)); return CLASS_E_CLASSNOTAVAILABLE; } /*********************************************************************** * DllCanUnloadNow (COMCAT.@) */ HRESULT WINAPI COMCAT_DllCanUnloadNow() { return dll_ref != 0 ? S_FALSE : S_OK; } /*********************************************************************** * DllRegisterServer (COMCAT.@) */ HRESULT WINAPI COMCAT_DllRegisterServer() { TRACE("\n"); return regsvr_register(regsvr_data); } /*********************************************************************** * DllUnregisterServer (COMCAT.@) */ HRESULT WINAPI COMCAT_DllUnregisterServer() { TRACE("\n"); return regsvr_unregister(regsvr_data); }

1 0

COM and threads
by Fabian Cenedese Nov. 26, 2002

Nov. 26, 2002

Hi There were some postings recently about CoInitialize and theads: http://www.winehq.com/hypermail/wine-devel/2002/11/0974.html "Sort of, the problem is that Wine doesn't support apartments yet, so it doesn't try to keep track of the threads that has called CoInitialize." I now have a problem that goes maybe in the same direction. I have an ocx which is again embedded in another ocx. In the wrapper are two threads (Msg and worker). I now get an error if the second thread tries to call a function from the embedded ocx. In the wine log I can find only one call to CoInitialize. This is right before the call of the second ocx: 0811c6d0:Call ole32.CoGetMalloc(00000001,4211275c) ret=65352782 0811c6d0:Ret ole32.CoGetMalloc() retval=00000000 ret=65352782 trace:ole:IMalloc_fnAlloc (292) trace:ole:IMallocSpy_fnPreAlloc (0x40a00944)->(292) trace:heap:RtlAllocateHeap (0x40380000,00000002,00000128): returning 403d5308 trace:ole:IMallocSpy_fnPostAlloc (0x40a00944)->(0x403d5308) trace:ole:IMalloc_fnAlloc --(0x403d5308) 0811c6d0:Call kernel32.InterlockedIncrement(403c9ad4) ret=65352c07 0811c6d0:Ret kernel32.InterlockedIncrement() retval=00000002 ret=65352c07 0811c6d0:Call ole32.CoCreateInstanceEx(65343308,00000000,00000000,00000000,00000000,00000000) ret=65352c8d 0811c6d0:Ret ole32.CoCreateInstanceEx() retval=80070057 ret=65352c8d 0811c6d0:Call ole32.CoSetState(653c3f80) ret=653527ec fixme:ole:CoSetState (0x653c3f80),stub! trace:ole:CoSetState -- release 0x653c3f80 now 0811c6d0:Call kernel32.InterlockedDecrement(403c9ad4) ret=65356c7e 0811c6d0:Ret kernel32.InterlockedDecrement() retval=00000001 ret=65356c7e some window, gdi32 and heap functions 08119650:Call gdi32.CreateRectRgnIndirect(406e26bc) ret=4083c19e trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d50c8 trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d5050 08119650:Ret gdi32.CreateRectRgnIndirect() retval=00001842 ret=4083c19e 08119650:Call gdi32.CombineRgn(0000184e,0000184e,00001842,00000001) ret=4083c1b3 trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d4ea0 trace:ole:IMalloc_fnFree (0x403d5308) trace:ole:IMallocSpy_fnPreFree (0x40a00944)->(0x403d5308 1) trace:heap:RtlFreeHeap (0x40380000,00000002,403d5308): returning TRUE trace:ole:IMallocSpy_fnPostFree (0x40a00944)->(1) 0811c6d0:Ret ole32.CoSetState() retval=00000000 ret=653527ec trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x65341543 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000010 The exception is right after CoSetState even if it says above that this is only a stub. It's that bad that I don't even have a call stack anymore. The function in the embedded ocx is never reached. But I can use the ocx in a simple VB proggy so I'd say registration is ok. I'm quite sure the problem lies in the two threads because it works better when I use only one thread in the wrapper ocx. Can somebody confirm this? Is there a workaround for this until wine supports COM with several threads? Thanks bye Fabi

2 1

RE: Wintab.dll technical issues.
by Patrik Stridvall Nov. 26, 2002

Nov. 26, 2002

> Firstly a quick note: > I have opened a bug for implementation of wintab.dll (Bug No. 1160) > > Now the questions: > > 1: Writing stubs. > I'll be taking up Patrik Stridvall's offer to write stubs for > anyone new > to wine development. Yes, I'm working on it right now. Will probably not finish tonight though. > One question about stubs: > What's the wine policy on stub return values? No general policy. It depends. > Should a stub always return an error? Normally stubs should indicate error (return NULL, FALSE or similar) and do SetLastError(ERROR_NOT_IMPLEMENTED). > Should/Can it return success? In some cases indicating success (return TRUE or similar), even though it not strictly correct, might be a good idea. It depends. Lying to the application should be avoided of course but sometimes it is nessary. > 2: Testing wintab.dll in Win98. > wintab.dll is quite complex for what it does. I guess you mean wintab32.dll. wintab.dll is the 16 bit variant AFAICS. > Therefore the only practical way to implement it is > to work on the functions and communication models that are > used by the apps I want it to support. Probably. > To do this, I need some tool that can log the function calls and > parameters to the DLL, while wunning Win98.The logging must > be able to > let the > programmer choose elements from data stuctures in > parameters/retvals to log. > Any ideas???? There are no good tools to do this AFAIK. But if you find any I'm very intrested. > I've attempted to use apis32 and built a wintab.fnl file for > wintab.dll. > Unfortunately apis32 doen't allow the logging of the contents of data > structs. Yes. APIS32 is the best AFAIK and it sucks pretty bad IMHO. > I would also like to know experinces with Spy++. > Wintab can send it's own custom messages, so I'm wondering how good > Spy++ is at detecting custom messages? > > I've used it many times before, but only to examine standard windows > messages. No idea, haven't used it for years. > 3: Coding standards. > I haven't found any coding standards associated with wine. > This is particularly important, as I'll be writing new source files. > Can someone point me to the standards? We have none. Decide for yourself. However please do not choose anything to unlik anything else in Wine.

2 1