- Wine-Devel - list.winehq.org

W->A calling and 32->16 calling
by Rolf Kalbermatter Dec. 2, 2002

Dec. 2, 2002

While going through the shell32 sources I found several issues with respect of this and at least one of them I couldn't find in the Janitorial list. ExtractIconW calls ExtractIconA which is mentioned but ExtractIconA calls InternalExtractIcon16 which is a 16 bit undocumented but exported function. I guess this should also go into the 32->16bit list somehow. I have worked on some fix for this but have to admit that this seems a little bit tricky. InternalExtractIcon16 also tries to open the file name with LoadLibrary16 so if it is a 16bit DLL the requested icons will still be extracted. PrivateExtractIcon and friends which are similar but also can handle negative icon indices which indicates that it should be treated as icon identifier, do as far as I can see not deal with 16bit libraries (they ultimatively call ICO_ExtractIconExW. This of course poses the question if the 32bit function ExtractIcon is supposed to return icons for 16bit libraries and if so, ExtractIconEx may actually also be required to do so. Below is a first attempt for a patch which does most probably not try to load resources from 16bit libraries yet. Also how about going with InternalExtractIcon16? Any comments to this? Rolf Kalbermatter Index: dlls/shell32/shell32_main.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.108 diff -u -r1.108 shell32_main.c --- dlls/shell32/shell32_main.c 21 Nov 2002 23:56:42 -0000 1.108 +++ dlls/shell32/shell32_main.c 2 Dec 2002 20:43:23 -0000 @@ -544,19 +544,18 @@ * FIXME * if the filename is not a file return 1 */ -HICON WINAPI ExtractIconA( HINSTANCE hInstance, LPCSTR lpszExeFileName, - UINT nIconIndex ) -{ HGLOBAL16 handle = InternalExtractIcon16(HINSTANCE_16(hInstance),lpszExeFileName,nIconIndex, 1); - TRACE("\n"); - if( handle ) - { - HICON16* ptr = (HICON16*)GlobalLock16(handle); - HICON16 hIcon = *ptr; - - GlobalFree16(handle); - return HICON_32(hIcon); - } - return 0; +HICON WINAPI ExtractIconA(HINSTANCE hInstance, LPCSTR lpszFile, UINT nIconIndex) +{ + HICON ret; + INT len = MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, NULL, 0); + LPWSTR lpwstrFile = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); + + TRACE("%p %s %d\n", hInstance, lpszFile, nIconIndex); + + MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, lpwstrFile, len); + ExtractIconW(hInstance, lpwstrFile, nIconIndex); + HeapFree(GetProcessHeap(), 0, lpwstrFile); + return ret; } /************************************************************************* @@ -564,18 +563,21 @@ * * FIXME: if the filename is not a file return 1 */ -HICON WINAPI ExtractIconW( HINSTANCE hInstance, LPCWSTR lpszExeFileName, - UINT nIconIndex ) -{ LPSTR exefn; - HICON ret; - TRACE("\n"); +HICON WINAPI ExtractIconW(HINSTANCE hInstance, LPCWSTR lpszFile, UINT nIconIndex) +{ + HICON hIcon = NULL; + + TRACE("(%p %s %d\n", hInstance, debugstr_w(lpszFile), nIconIndex); - exefn = HEAP_strdupWtoA(GetProcessHeap(),0,lpszExeFileName); - ret = ExtractIconA(hInstance,exefn,nIconIndex); + if (nIconIndex == -1) + return (HICON) PrivateExtractIconsW(lpszFile, -1, 0, 0, NULL, 0, 0, 0); - HeapFree(GetProcessHeap(),0,exefn); - return ret; + ExtractIconExW (lpszFile, nIconIndex, &hIcon, NULL, 1); + if (hIcon) + return hIcon; + return (HICON)1; } + typedef struct { LPCSTR szApp;

1 0

Re: Wine 0.9 TODO v0.6
by Hetz Ben-Hamo Dec. 2, 2002

Dec. 2, 2002

> As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment I looked at the screenshots. Looks very impressive but very problematic.. Why problematic? simple: most of those applications requires many tweaks to run. Example: try to install Office 2k on the latest wineHQ. You'll have lots of problems installing it, and even if you install, you'll need to do "reboot" - which is not available unless you have CrossOver office. Same goes to many applications which have screenshots there.... So think what will happend if users will download wine-snapshot and won't be able to install the apps that appears in the screenshots? lots of anger, flames, false bug reports, you name it ;) Thanks, Hetz

2 1

Re: Cabinet update
by Alexandre Julliard Dec. 2, 2002

Dec. 2, 2002

Patrik Stridvall <ps(a)leissner.se> writes: > *** cabinet > > * include/fci.h, > include/fdi.h, > dlls/cabinet/Makefile.in, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > - Added previously forgotten file main.c. There is no reason to have a stub DllMain, it only slows things down and makes no difference for the app. We should only add it if/when we really need it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Winelib - MFC application
by Ronald MALLET Dec. 2, 2002

Dec. 2, 2002

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

3 3

RE: strcat+strcat+strcat == baaad
by Medland, Bill Dec. 2, 2002

Dec. 2, 2002

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. I think this statement has to be tightened. I am sure you know exactly what you mean, Alexandre, and I believe that I and many others do. However I think we need to mention that one needs to consider that the strings passed in may be bad, e.g. unterminated. Either one uses that actual measured lengths of the strings when allocating or one checks the lengths of the strings against the allocated space. In particular one DOES NOT allocate on the basis of some wishy-washy documentation statement or a hard-coded constant that the caller may well have ignored. > > -- > Alexandre Julliard > julliard(a)winehq.com > > Bill Medland

3 2

How to fix display errors?
by Ferenc Wagner Dec. 2, 2002

Dec. 2, 2002

Hello, I decided to forward a previous post of mine from the users' newsgroup, since I got no answers there, and consider this a developer question: I'd like to correct some bugs. Having read the Developers' Guide didn't help me much: the relevant topic was empty (the program runs, but shows some errors). Perhaps you can point me in the right direction (I mean: source file in the tree)? Below is the article. See a screenshot at http://afavant.elte.hu/~wferi/wine.png (25K). It exhibits several slight problems. 1. The scrollable list has no border (Suchanfrage window, above the Phrasensuche checkbox). 2. The text input field (with Goethe in it) has no border, too. 3. The "Minimize" button is misplaced: clicking to the right of it invokes its action, the button itself is not clickable. 4. The little toolbar window to the right looks strange, but what is worse, it is sticky: appears on every viewport (It's not managed by fvwm2, like the main window.) The Suchanfrage subwindow is not sticky. While executing the program, I get the following messages: err:toolbar:ToolbarWindowProc unknown msg 0465 wp=0000004c lp=412c1d70 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub err:statusbar:StatusWindowProc unknown msg 0486 wp=0000 lp=00000000 err:toolbar:ToolbarWindowProc unknown msg 0486 wp=00000000 lp=00000000 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub Is there anything I can do about the above (cosmetic) errors? I use a recent CVS checkout (Wine 20021125), and I know C programming, but have no experience with graphics and Windows. Feri.

1 0

Winelib - MFC application
by jaymz＠free.fr Dec. 2, 2002

Dec. 2, 2002

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

1 0

Screenshots v0.1
by Brian Vincent Dec. 2, 2002

Dec. 2, 2002

I've gotten a lot of great screenshots over the past few weeks. I've put together a preview you can find here: http://www.theshell.com/~vinn/ss/preview.html Be warned, the format isn't the best, the thumbnails aren't even close to optimized, I only looked at it in one browser, and it might even steal your lunch money. Random notes: - there's lots of great shots not on the thumbnails page - most likely there's a reason, not 800x600, didn't scale well, or I simply overlooked it - you can find all of the screenshots at: http://www.theshell.com/~vinn/ss - the images predominantly are PNG, though there are quite a few JPEGs. No GIF. - Special thanks to: Thomas Wickline Carlos Lozano David Buchmann Guido Grazioli Ender Juliasz Gonera Michael Krasucki Mike Hearn Rick Romero Robert Shade Rory King Tony Lambregts tavis Okay, if you've read this far maybe you're expecting something to prompt discussion. One of the things you'll notice is there's a lot of screenshots on there there almost certainly don't run out of the box. In some instances the folks above listed exactly what they had to do to make it run. Personally, I don't think it matters. We already have the apps DB and the proposed "Gold/Silver/.." apps list, I really don't think we need more than a link to one of those. Also, a few weeks ago there was a lot of discussion of a new WineHQ site. Any progress on that front? -Brian Vincent

3 2

RE: strcat+strcat+strcat == baaad
by Patrik Stridvall Dec. 2, 2002

Dec. 2, 2002

> I suggest implementing strlcat and strlcpy, as in OpenBSD. I > can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static > func), or in > some library that will be linked (statically, I hope). Ideas? Since the do exists on some platforms (OpenBSD and FreeBSD) the obvious place to put them would be library/port.c like any other function that doesn't exists on all platforms. Just remember to add detect in configure.ac and use the HAVE_ macro in library/port.c As for (re)writing them. Why not just borrow the source from FreeBSD or OpenBSD. They both have licenses compatible with Wine. No need to reinvent the wheel.

1 0

Adding support for xxx_test.exe all
by Francois Gouget Dec. 2, 2002

Dec. 2, 2002

When running the tests on Windows you can either do 'xxx_test.exe' which gives you a list of the available tests for this executable, or 'xxx_test.exe foo' which runs test foo, and only test foo. So I propose the following patch which makes it possible to run 'xxx_test.exe all' which runs all the tests implemented by that executable. Do others find this patch acceptable? Useful? Index: include/wine/test.h =================================================================== RCS file: /home/wine/wine/include/wine/test.h,v retrieving revision 1.7 diff -u -r1.7 test.h --- include/wine/test.h 30 Oct 2002 20:36:21 -0000 1.7 +++ include/wine/test.h 30 Nov 2002 04:46:23 -0000 @@ -319,7 +319,23 @@ if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p); if (!argv[1]) usage( argv[0] ); - return run_test(argv[1]); + if (strcmp(argv[1], "all") == 0) + { + const struct test* test; + int status=0; + + for (test = winetest_testlist; test->name; test++) + { + fprintf(stderr, "Testing %s\n", test->name); + status+=run_test(test->name); + fprintf(stderr, "\n"); + } + return (status <= 255) ? status : 255; + } + else + { + return run_test(argv[1]); + } } #endif /* WINETEST_WANT_MAIN */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

2 2