wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Debugger Woes
by Robert Shearman 03 Jan '04

03 Jan '04

Hi, After the automatic glibc detection changes the Wine debugger stopped loading symbols correctly, making it harder to debug programs. I only recently noticed this due to lack of disk space and not compiling and installing the whole tree on a cvs update. However, I have now spent some time looking at the problem. By applying the following patch to winedbg, I saw that the address for the ELF debugging section was not being found properly. Index: programs/winedbg/stabs.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/stabs.c,v retrieving revision 1.11 diff -u -r1.11 stabs.c --- programs/winedbg/stabs.c 15 Dec 2003 19:53:08 -0000 1.11 +++ programs/winedbg/stabs.c 1 Jan 2004 17:49:02 -0000 @@ -1625,6 +1625,7 @@ do { if (!DEBUG_READ_MEM_VERBOSE((void*)dyn_addr, &dyn, sizeof(dyn))) goto leave; + WINE_TRACE("dyn.d_tag is %d\n", dyn.d_tag); dyn_addr += sizeof(dyn); } while (dyn.d_tag != DT_DEBUG && dyn.d_tag != DT_NULL); if (dyn.d_tag == DT_NULL) goto leave; An example from loading "winedbg --debugmsg +winedbg notepad": trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1448084550 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is -997982209 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1457883477 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1455977869 ... trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 0 I believe these invalid values are being caused because we are mmap'ing "wine" and reading in the values from the .dynamic section, but the ".dynamic" section hasn't been intialized by the ELF loader. This previously wasn't as issue since "wine" would already have been loaded. However, now "wine" exec's "wine-kthread" or "wine-pthead" as appropriate and then exits and so is no longer in memory. This appears to have been anticipated with the check further up in the stabs.c file that examines the "WINELOADER" environment variable to find the file to mmap. If this is set to "wine-pthread", for example, then the problem goes away. Hence the attached patch. Perhaps the real fix should be made to programs/winedbg/stabs.c. We could either not use the ".dynamic" section somehow or use the dlsym rather than mmap so that we properly initialize the ".dynamic" section. Rob P.S. above trace with patch applied: trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 12 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 13 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 4 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 5 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 6 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 10 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 11 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 21

2 1

Re: Printing bugfixes
by Dmitry Timoshkov 03 Jan '04

03 Jan '04

"Mike Hearn" <mike(a)theoretic.com> wrote: > + num = sizeof(PrinterName); > + if (!GetDefaultPrinterW(PrinterName, &num)) > + WCHAR default_name[255]; > + DWORD default_name_size = sizeof(default_name); > + > + if (GetDefaultPrinterW(default_name, &default_name_size) == 0) { You should pass the size of buffer in characters, not in bytes to GetDefaultPrinter. -- Dmitry.

1 0

Re: Endless WM_PAINT loop fix
by Alexandre Julliard 02 Jan '04

02 Jan '04

Rein Klazes <rklazes(a)xs4all.nl> writes: > Changelog: > windows : painting.c > If RedrawWindow is called with the RDW_INVALIDATE flag, if the > UpdateRgn parameter is a NULLREGION and the Window has no update > region yet, ignore the call. This should be integrated with the update region calculations, we shouldn't add such special cases outside of the main code. -- Alexandre Julliard julliard(a)winehq.com

1 0

wine-bugs Mailings Enhancement request
by Uwe Bonnes 02 Jan '04

02 Jan '04

A happy new year to everybody! As a lot of wine-bugs are reworked(mostly thanks to Markus), I get a lot of mails from wine-bugs. However it is hard to follow the threads by only getting information about the last status update. At least the information of the name of the originator of bug should be resent, perhaps even the last two or three status updates. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: PATCH: Fix DLL constructors on OpenBSD
by Alexandre Julliard 02 Jan '04

02 Jan '04

wiml(a)underhill.hhhh.org (Wim Lewis) writes: > Use the GCC attribute((constructor)) syntax for DLL initializer hooks > if possible, instead of the inline-asm syntax. The dll init routine needs to be in the .init section in order to be called first, attribute((constructor)) is not good enough. Why doesn't it work on OpenBSD? Is the section name different? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [WINEALSA] Fix compilation issue with ALSA 0.5
by Christian Costa 02 Jan '04

02 Jan '04

Christian Costa wrote: > Hi, > > This patch fixes a compilation issue with ALSA 0.5 (reported by Carl > Sopchak) > that appears when adding WaveIn support. > > Bye. > > Changelog : > Fix compilation issue with ALSA 0.5. > > Christian Costa titan.costa(a)wanadoo.fr > > > BTW: Happy new year to all! Bye, Christian

1 0

Re: Printing bugfixes
by Huw D M Davies 02 Jan '04

02 Jan '04

On Thu, Jan 01, 2004 at 08:23:20PM +0000, Mike Hearn wrote: > ChangeLog: > - Write out default printer name in the order used by WinME > - Support PRINTER_ENUM_DEFAULT > - Add FIXME for enumerating print providers > > I'd appreciate somebody with a CUPs and lpr setup ensuring the order > change doesn't cause regressions. It appears correct to me, but as the > code worked before even though it looked like it shouldn't I might be > wrong. Actually I don't see why we need a different name and devname we should just use devname for both entries instead. I think it's a hangover from some old code Your patch however looks wrong, you're adding a default printer with port LPR:LPT1, the spooler will try to print with the command lpr -PLPT1 which won't work. You really want to set the port to LPT1: Huw.

2 2

Re: REBAR: on a RB_SETBANDINFO message only redraw the rebar if something changed
by Dimitrie O. Paun 02 Jan '04

02 Jan '04

On January 2, 2004 10:50 am, Mike McCormack wrote: > This stops IE's toolbar from flickering when moving the mouse over links. Happy, happy, joy, joy... Thanks Mike!!! -- Dimi.

1 0

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 02 Jan '04

02 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

Re: DMUSIC: my latest work
by Dimitrie O. Paun 01 Jan '04

01 Jan '04

On January 1, 2004 04:25 am, Rok Mandeljc wrote: > Hey everyone, > > I finally found some time to organise my dmusic work of last two months > in useful patch. Dmusic is now DX9 compatible, we have almost fully > implemented (but not working :( ) > IDirectMusicCollection/IDirectMusicInstrument, fully implemented > IDirectMusicContainer and almost completely (but fully working I believe > IDirectMusicLoader)... Nice! What would you say is the status of DMusic (70-80-90% complete?) > => oh and if somebody is interested in test programs I wrote & used and > some docs on dark sides of dmusic (written by myself ;)), mail me and > you'll get them in 24 hours ;) Shouldn't we get this into the tree somewhere? (either as comments in the code, or as documentation in the Devel Guide). Ditto for test program (not sure where it should go though...) > => and happy New Year everyone! Happy New Year to you too! -- Dimi.

1 0

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

Just adding an entry in the.spec file makes somethin build?
by Joshua Walker 01 Jan '04

01 Jan '04

Are .spec files automahicly built? Adding an entry to the .spec file does what exactly? From my standpoint all it does is add an entry to the documentation thats generated by c2man.pl, but it's undocumentabale, not linked to anything, and just sits there. I'm assuming you *MUST* have a function, or a declration, or something the jive with the .spec file? On second thought, this is more of a functionallity question. Here's more on documentation... I wanted to say this after I finished documenting the API of a DLL, but it's more releivent here. Many people program open source for many reasons. I simply want to learn the Win32 API. I have no idea why, I guess I'm just cerious about how it works. As I am sitting here placing comments into code I am reminded of a short story in "The Hitchhiker's Guide to the Galaxy" In the story there was an alien who had immortility accidently placed upon him by way of a particle accelorator, a rubber band, and I think some tea... But I'm not too sure about that bit. Anyway he had a grand old time simply outliving the hell out of everyone. After a while he became biter an jaded, he needed something to do to bide his time and so he decided to insult the universe. The worst bit, and the part that he fought so hard to maintain, is that he decided to do it *Alphabectally* I feel much like this guy, I'm starting in advapi32.dll and methotcally working my way through it. At first I wanted to do an end-to-end API documentaion, but I'm hampered by things that arn't implmented yet. That's fine, I'll just do an end-to-end Wine API documentation instead. I do not have the skills to fill in code myself. I don't even have a test suite (Read:windows computer) to check myself against anyway. I have found that when I document the APIs, that the subs tend to stand out between the hyperlinks. It almost feels like they are saying "Look at me! Not only do I not fuction, but I can't get a lousy hyperlink either!" And so I think I have found another motivtion to do Open Source programming. Guilt. Yes, I am now panning to guilt people into impmentation. All those entries look soooo pretty it it wasn't for those ugly, black stubs in there. I would like to have the entire API in there, stubbed out, to simply enhance the guilt. But I shall just "do what's there" I just dispuse going through what I've written when I have an eppifiny of some sort. I have to do it again anyway as I need to link up some advapi32 calls to some ntdll calls. I just learnd that one was a front end to another... Anyway, I guess this is a rounds about way of saying this, but I'll just do what's there, and hopefully guilt others into implemtation ^_^ -Joshua P.S. If I find someone who has implemented something after I've gon through the DLL, only to find they didn't bother to make a simple documentation header for it.... Well, then I'd just be really sore....

2 1

Docs
by Ivan Leo Murray-Smith 01 Jan '04

01 Jan '04

Hi list, I've noticed this  in getting.sgml, I've recently changed a few things in it, but there isn't a cvs.sgml file, should this warning go? Ivan.

2 1

GetModuleFileName mysteries
by Ralf Juengling 01 Jan '04

01 Jan '04

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

Re: MCI #4: Add support for many MCIWNDM_ messages and some MCI_ commands
by Dimitrie O. Paun 31 Dec '03

31 Dec '03

On December 30, 2003 11:48 am, Dmitry Timoshkov wrote: > + * Add support for all remaining MCI_ commands and MCIWNDM_ messages. > + * Add support for all MCIWNDF_ flags. An explicit list of MCI_ commands/MCIWNDM_ messages/MCIWNDF_ flags would be much appreciated (if it's under 30ish items). This would give a much better indication of the amount of work left to do. -- Dimi.

3 4

Re: PATCH: dlls/winmm/wineoss/audio.c
by Alexandre Julliard 31 Dec '03

31 Dec '03

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > Tests by a FreeBSD user and discussions with one of the FreeBSD sound > maintainers confirmed that this is the right fix for that platform. > > I'm not sure whether you want to make this change in general, for all > platforms, so for now I have embedded it in an #if(n)def. I think we should do that on all platforms, yes. And you probably want to fix OSS_WaveInInit too. -- Alexandre Julliard julliard(a)winehq.com

2 1

Silly question, sloghtly off topic
by Joshua Walker 31 Dec '03

31 Dec '03

If you replace a win9x advapi32.dll with a winNT advapi32.dll, do you gain the extra security features? I'm guessing no... -Joshua

2 1

PATCH - winebrowser
by Chris Morgan 30 Dec '03

30 Dec '03

Has Rein's fix for mozilla and Ivan's additional browsers. Tried to clean the script up a little bit, could probably still use some work but I'm no script guru. Chris * tools/winebrowser, tools/wineinstall, tools/Makefile.in, winedefault.reg Chris Morgan <cmorgan(a)alum.wpi.edu> Add HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key and value. Winebrowser script. Makefile changes to install/remove script. Wineinstall should create a simlink from windows/winebrowser.exe to the location of winebrowser on the machine.

1 0

Re: Add support for some other MCI_ commands and implement mciSendCommandW
by Alexandre Julliard 30 Dec '03

30 Dec '03

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -84,7 +84,16 @@ BOOL VFWAPIV MCIWndRegisterClass(HINSTAN > { > WNDCLASSW wc; > > - wc.style = CS_VREDRAW | CS_HREDRAW | CS_DBLCLKS | CS_OWNDC; > + /* Since we are going to register a class belonging to MSVFW32 > + * and later we will create windows with a different hInstance > + * CS_GLOBALCLASS is needed. And because the second attempt > + * to register a global class will fail we need to test whether > + * the class was already registered. > + */ > + if (GetClassInfoW(MSVFW32_hModule, mciWndClassW, &wc)) > + return TRUE; > + This is not thread-safe; if you need to know why the class creation failed you should check the last error returned from RegisterClassW. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Allow regsvr32 to register multiple DLLs at once
by Alexandre Julliard 30 Dec '03

30 Dec '03

Mike Hearn <mike(a)theoretic.com> writes: > When you just get the urge to reregister your entire windows/system > directory... > > Mike Hearn <mike(a)theoretic.com> > Allow regsvr32 to register multiple DLLs even if some fail regsvr32 is a standard Windows program, we shouldn't invent new options that don't exist on Windows. -- Alexandre Julliard julliard(a)winehq.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel