December 2003 - Wine-devel - list.winehq.org

Status ToDo's #2
by Tom 04 Jan '04

04 Jan '04

Comments, Suggestions? Tom

5 6

Congradulations :-}
by Boaz Harrosh 04 Jan '04

04 Jan '04

Just wanted to let people know. And share this happy moment with my fellow workman I have successfully Beta released a WinLib port of a, 1 million lines of code, windows program. QA will Install a first Linux Machine and will start to bang on it tomorrow. (Well more like an advanced Alfa I guess) Technologies successfully compiled and running in the Project: - Windows GUI & API (wrapped in an Old C++ lib, ZAFF). - ODBC under CRecordSet from MFC - I use the MSSQL drivers, SQLing data from a neighboring WinXP-SQL Server. I used an mdac.exe installation application from Microsoft. With ODBC32 native DLL. - General MFC contains, Strings, OleDispatch OleVariant OleBSTR... and even some GUI. - Actually to manage that I had an MSVC++ wizard generated MFC MDI Application with ODBC access and forms. Which helped me debug the MFC library. So MFC is pretty much covered. - ATL/WTL OCX hosting and General ATL use for anything COM. - Here too a WTL app-wizard generated MDI application with IE and other OCXes on Forms help me verify the ATL subsystem. Including support for "uuidof", "#pragma property" and more. Hosting and Events work fine. ( actually ActiveX controls compile too, but TLB problem must be resolved.) - A solution for Linking with C++ shared libraries that in-turn also use windows API. (I call them C++ fake DLLs.) - C++ STL from STLPort ported to Wine to compile using msvcrt (and MFC) And more stuff I cannot remember now. By far the biggest problem was the msvcrt vs STL. and other native C++. This caused a big Linking problem where STL would bypass msvcrt but other application code would not. This proved to be fatal. From circular linking to allocators not matching to Libraries not able to load. Since MFC and ATL would not even think to compile with out msvcrt Headers and lib the issue had to be resolved. The only way I managed to solve it all is by directly linking msvcrt GCC style into STLPort and into every module there of. Now that would make some conflicts with OCX's like IE6 that can only run with native msvcrt.dll, so I also had to change it's name. One of the thing I would like to eventually do is Make a static msvcrt library using same source code but having different make files to be used in such situations where it has to be directly linked. Tomorrow I will start synchronization with wine current tree. Once I have it synced (2 days max). I will need someone to help me and guide me on how to send it all in. Dimi, will that be you? So I guess the scores are: Wine vs Windows 1:1 World vs Microsoft 3:10 (we are making progress, wait for the last round) Boaz vs GCC 7:4 Good vs Evil (I better not say) Happy new Year to all Free Life Boaz

5 16

Re: lParam of WM_CREATE for MDI children
by Steven Edwards 02 Jan '04

02 Jan '04

Hello Dmitry, --- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > applications use something like the following code in order to pass > a custom parameter to a newly created MDI child: <snip> > Any ideas how to proceed without breaking too much assumptions in > the current code? You may want to take a look at the ReactOS implementation of MDI as we have done quite a bit of work on this and shell32 of late to get the ReactOS Explorer working. I dont know if Filip or Martin has already fixed the MDI bugs but if so we should have something to merge when Alexandre gets back. Thanks Steven __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

2 2

unknwn.h: unknwn.idl
by Boaz Harrosh 01 Jan '04

01 Jan '04

2 Questions 1) if I do "make depend" than edit unknwn.idl (or any other idl) than do "make" should a new unknwn.h be compiled? Well it does not. If I "cd include" and "make" than nothing is done either. only if I do "make unknwn.h" it will compile. 2) In order for ATL to compile I need below code in my unknwn.h file. I could not fined a way to do it with WIDL. I have looked in Microsoft (vc6) header/idl and it looks they had the same problem. And below code was added by hand. Now if the answer to Q1 is "No not done automatically" than I guess I can submit a patch for unknwn.h only. could I also submit a patch to include/Makefile.in to remove unknwn.idl from the list of idl files so it will not accidentally over-write unknwn.h? <unknwn.h snippet> ... DEFINE_GUID(IID_IUnknown, 0x00000000, 0x0000, 0x0000, 0xc0,0x00, 0x00,0x00,0x00,0x00,0x00,0x46); #if defined(__cplusplus) && !defined(CINTERFACE) #if !defined(WINE_NO_UUIDOF) #include <wine/uuidof.h> extern "C++" { #endif #ifdef ICOM_USE_COM_INTERFACE_ATTRIBUTE struct __attribute__((com_interface)) IUnknown #else struct IUnknown #endif { virtual HRESULT STDMETHODCALLTYPE QueryInterface( REFIID riid, void** ppvObject) = 0; virtual ULONG STDMETHODCALLTYPE AddRef( ) = 0; virtual ULONG STDMETHODCALLTYPE Release( ) = 0; #if !defined(WINE_NO_UUIDOF) template <class Q> HRESULT STDMETHODCALLTYPE QueryInterface(Q** pp) { return QueryInterface(__uuidof(Q), (void**)pp); } #endif }; #if !defined(WINE_NO_UUIDOF) } // extern "C++" #endif #else ... </unknwn.h snippet> I have tried below simple idl code but it will go to all the wrong places <bad unknwn.idl code> ... interface IUnknown { typedef [unique] IUnknown *LPUNKNOWN; HRESULT QueryInterface( [in] REFIID riid, [out, iid_is(riid)] void **ppvObject); ULONG AddRef(); ULONG Release(); cpp_quote("#if !defined(WINE_NO_UUIDOF)") cpp_quote("template <class Q>") cpp_quote("HRESULT STDMETHODCALLTYPE QueryInterface(Q** pp)") cpp_quote("{") cpp_quote(" return QueryInterface(__uuidof(Q), (void**)pp);") cpp_quote("}") cpp_quote("#endif") } cpp_quote("#if !defined(WINE_NO_UUIDOF)") cpp_quote("} /*extern C++*/") cpp_quote("#endif") ... </bad unknwn.idl code>

4 8

Missing exports?
by Joshua Walker 01 Jan '04

01 Jan '04

So I'm still stumbling through advapi32 and there seems to be some functions that were not exported. ANy reason why? For example, AccessCheckByType was but AccessCheckByTypeAndAuditAlarm, AccessCheckByTypeResultList, AccessCheckByTypeResultListAndAuditAlarm, and AccessCheckByTypeResultListAndAuditAlarmByHandle were not mentioned in the .spec file. Are these missed exports? Do they need to be at least stubbed? I know this all may seem bit anal, what with about a few thousand spec'ed APIs that need to be documented and all. I would just like to fill in the blankes as much as possable the first time through. I've already had to backtrack three times to add intresting comments I found important.(Function XYZ is only avilible on WinNT 3.1 or higher) It would be nice to at least have a fully spec'ed out DLL. -Joshua

6 6

New registry key adding patch
by Zimler Attila 01 Jan '04

01 Jan '04

Hi, I made the regedit program able to add new registry key (however, the key does not appear until next run of regedit in the browser tree - as I consulted it with Dimitrie, it will be handled later). The diff is made against todays cvs tree (as 2003 december 31). Attila PS: Dimitrie: what is the next step to do? diff -r -d -c -N wine/programs/regedit/edit.c wine.new_regkey/programs/regedit/edit.c *** wine/programs/regedit/edit.c 2003-12-12 04:08:59.000000000 +0000 --- wine.new_regkey/programs/regedit/edit.c 2003-12-31 14:36:44.000000000 +0000 *************** *** 17,22 **** --- 17,25 ---- * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ + /* Modified by Attila ZIMLER <hijaszu(a)hlfslinux.hu> on 28th of dec 2003. + - New key adding is now supported. + */ #define WIN32_LEAN_AND_MEAN /* Exclude rarely-used stuff from Windows headers */ *************** *** 91,96 **** --- 94,129 ---- return FALSE; } + BOOL CreateKey(HKEY hKey) + { + LONG lRet; + HKEY retKey; + char* keyName = 0; + unsigned int keyNum = 1; + + /* If we have illegal parameter return with operation failure */ + if (!hKey) return FALSE; + + /* try to find out a name for the newly create key */ + /* TODO: warning is issued because asprintf's implicit declaration, + I tried to declare it as + extern "C" ssize_t asprintf(char**, const char**, ...) + which is the format of this function, but it seems not helping. + Don't know why :( + */ + asprintf(&keyName, "new key"); + lRet = RegOpenKey(hKey, keyName, &retKey); + while (lRet == ERROR_SUCCESS) { + asprintf(&keyName, "new key %u", ++keyNum); + lRet = RegOpenKey(hKey, keyName, &retKey); + } + + lRet = RegCreateKey(hKey, keyName, &retKey); + + free(keyName); + return lRet == ERROR_SUCCESS; + } + BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName) { DWORD valueDataLen; diff -r -d -c -N wine/programs/regedit/framewnd.c wine.new_regkey/programs/regedit/framewnd.c *** wine/programs/regedit/framewnd.c 2003-12-12 04:08:59.000000000 +0000 --- wine.new_regkey/programs/regedit/framewnd.c 2003-12-31 14:38:34.000000000 +0000 *************** *** 469,474 **** --- 469,478 ---- case ID_EDIT_COPYKEYNAME: CopyKeyName(hWnd, _T("")); break; + case ID_EDIT_NEW_KEY: + if (CreateKey(hKey)) + RefreshListView(g_pChildWnd->hListWnd, hKeyRoot, keyPath); + break; case ID_REGISTRY_PRINTERSETUP: /*PRINTDLG pd;*/ /*PrintDlg(&pd);*/ diff -r -d -c -N wine/programs/regedit/main.h wine.new_regkey/programs/regedit/main.h *** wine/programs/regedit/main.h 2003-12-12 04:08:59.000000000 +0000 --- wine.new_regkey/programs/regedit/main.h 2003-12-31 14:39:57.000000000 +0000 *************** *** 93,98 **** --- 93,99 ---- extern LPCTSTR GetItemPath(HWND hwndTV, HTREEITEM hItem, HKEY* phRootKey); /* edit.c */ + BOOL CreateKey(HKEY hKey); BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName); #endif /* __MAIN_H__ */

2 8

Renaming registry keys...
by Robert van Herk 01 Jan '04

01 Jan '04

Hi! Does anybody have a C algorithm to rename a registry section using the Win32 API? I need such a thing for winecfg, but Win32 doesn't seem to have a RegKeyRename api-call... Grtz, Robert

3 5

GetModuleFileName mysteries
by Ralf Juengling 31 Dec '03

31 Dec '03

I have some Windows code that uses GetModuleFileName in order to read some additional files at runtime that are expected at certain place relative to the executable. In Wine, GetModuleFileName doesn't work as intended, and I have trouble to track down the problem. I had to use winemaker's "wrap" option in order to work around initialization problems (C++ code). So the application, "memview.exe.so" is just a small wrapper which loads "memview.dll.so" via "LoadLibrary" and calls the dll's "WinMain". The startup script (a copy of wineapploader named "memview") determines the application's name to be "memview.exe" and thus executes "wine memview.exe". Under these circumstances, GetModulFileName yields "C:\WINDOWS\SYSTEM\memview.exe", which is not correct. If I alter the winapploader script so that wine gets called with "memview.exe.so" instead, GetModuleFileName yields "Z:\local\builts\phaeaco-20031216\src\memview\memview.exe", which is the correct path (but "memview.exe" doesn't exist). There is a second application which I built the very same way (i.e. using a small wrapper "phaeaco.exe.so" which loads the actual code contained in the DLL "phaeaco.dll.so"). This application also uses GetModuleFileName; here it always yields "C:\WINDOWS\SYSTEM\phaeaco.dll", no matter whether the application name given to wine by the wineapploader script is "phaeaco.exe" or "phaeaco.exe.so". This is a confusing picture. Could somebody point out what the expected result of GetModuleFileName is for this scenario (the full path to the dll, I guess) and how it comes about that it yields a path "C:\WINDOWS\SYSTEM\..."? I observed this with Wine-20031118, haven't tested more recent versions. Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

5 8

Happy 2004
by Ivan Leo Murray-Smith 31 Dec '03

31 Dec '03

Happy New Year from the Central European Time Zone! Ivan.

1 0

Re: Simple arguments check
by Alexandre Julliard 31 Dec '03

31 Dec '03

Mike Hearn <mike(a)theoretic.com> writes: > Index: dlls/shell32/pidl.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/pidl.c,v > retrieving revision 1.94 > diff -u -r1.94 pidl.c > --- dlls/shell32/pidl.c 4 Nov 2003 04:21:01 -0000 1.94 > +++ dlls/shell32/pidl.c 25 Dec 2003 19:32:48 -0000 > @@ -1234,10 +1234,19 @@ > LPSHELLFOLDER shellfolder; > > TRACE_(shell)("(pidl=%p,%p)\n",pidl,pszPath); > - pdump(pidl); > > - if (!pidl) return FALSE; > + if (!pidl) { > + ERR_(shell)("argument check failed: pidl == null\n"); > + return FALSE; > + } > + > + if (!pszPath) { > + ERR_(shell)("argument check failed: pszPath == null\n"); > + return FALSE; > + } The ERRs are useless. If Windows does a NULL check, then we should do one too, without any error message; if Windows doesn't, then we shouldn't check at all. -- Alexandre Julliard julliard(a)winehq.com

3 4