Re: some questions (required for my dmusic work)
2. I still can't figure how to implement interface that consist of two interfaces (I have IDirectMusicLoaderStream which should consist of IStream and IDirectMusicGetLoader). Can someone send me detailed instructions how to do it? (I can't find any examples) I think what you want to do is implement two interfaces in one object, which is a bit different than putting two interfaces in one interface (every interface has IUnknown in it). For an example, see the implementation of the StdComponentCategoriesMgr in dlls/comcat, which might be slightly unusual because there is just one static instance rather than potentially many dynamically created instances. The implementation is broken down like this: comcat_private.h declaration of ComCatMgrImpl struct with three Vtbl pointers manager.c implementation of IUnknown, used by other interface impls too, and static ComCatMgrImpl instance, would normally be alloc'd and init'd information.c implementation of ICatInformation, partially forwards to IUnknown register.c implementation of ICatRegister, partially forwards to IUnknown There are probably other examples, but that is one I'm familiar with.
Re: [DSOUND?] SMP problem workaround, more info
On Sat, Jun 14, 2003 at 08:13:42PM -0400, OverrideX wrote:
guessing it has to do with how ss2 is calling sounds, since it seems
directly related to dsound underruns, and dsound_main.c says in the todo
it's missing critical section locking in some parts of it's code, and
I don't think the missing critical sections in AddRef and Release are
related to your problem, but just in case, I have changed the AddRef and
Release in dsound_main.c to use InterlockedIncrement and
InterlockedDecrement. Does this help? Or at least, does it avoid
breaking it worse?
--
John K. Hohm
[EMAIL PROTECTED]
Index: dlls/dsound/dsound_main.c
===
RCS file: /home/wine/wine/dlls/dsound/dsound_main.c,v
retrieving revision 1.83
diff -u -r1.83 dsound_main.c
--- dlls/dsound/dsound_main.c 22 May 2003 03:39:13 - 1.83
+++ dlls/dsound/dsound_main.c 18 Jun 2003 00:10:13 -
@@ -690,14 +690,14 @@
static ULONG WINAPI IDirectSoundImpl_AddRef(LPDIRECTSOUND8 iface) {
ICOM_THIS(IDirectSoundImpl,iface);
TRACE((%p) ref was %ld\n, This, This-ref);
- return ++(This-ref);
+ return InterlockedIncrement(This-ref);
}
static ULONG WINAPI IDirectSoundImpl_Release(LPDIRECTSOUND8 iface) {
HRESULT hres;
ICOM_THIS(IDirectSoundImpl,iface);
TRACE((%p), ref was %ld\n,This,This-ref);
- if (!--(This-ref)) {
+ if (!InterlockedDecrement(This-ref)) {
UINT i;
timeKillEvent(This-timerID);
@@ -1090,14 +1090,14 @@
DSCF_AddRef(LPCLASSFACTORY iface) {
ICOM_THIS(IClassFactoryImpl,iface);
TRACE((%p) ref was %ld\n, This, This-ref);
- return ++(This-ref);
+ return InterlockedIncrement(This-ref);
}
static ULONG WINAPI DSCF_Release(LPCLASSFACTORY iface) {
ICOM_THIS(IClassFactoryImpl,iface);
/* static class, won't be freed */
TRACE((%p) ref was %ld\n, This, This-ref);
- return --(This-ref);
+ return InterlockedDecrement(This-ref);
}
static HRESULT WINAPI DSCF_CreateInstance(
Re: LockFile() and UnlockFile() are working
This resolution will make a ton of business apps based on desktop database software that much closer to working. I'm not so sure. I expect most database software depends on the mandatory nature of LockFile(), i.e. that a ReadFile() or WriteFile() from another process on a locked region fails with ERROR_LOCK_VIOLATION. Typically, one process will LockFile() an area, then update on-disk structures in such a way that another process reading during the update would get confused were it not for ReadFile() refusing to read the locked bytes. Note that the reading process does not LockFile() to read, it just tries ReadFile() and handles its failure (typically by waiting and trying again later). For database software that uses read/write locks via LockFileEx(), the standard Unix advisory lock semantics are just fine, and those patches are indeed the ticket. However, advisory locking is generally more difficult to manage, and LockFileEx() is not supported on Windows 95/98/Me, so I doubt many apps use it. From what I can tell, mandatory locking on Linux involves tricks like using a special mount option, and setting the SGID bit of the file to be locked before the locking process starts; I'm not sure which other Unixen even support it.
Re: TreeView notifications fix
Well, WinAmp seems to use CreateWindowExW to create the window, but I can't find where the window class is registered, it doesn't seem to appear in a +class trace anywhere. The string name is #32770, so maybe it's internal. Indeed, here is a list of system classes: Class Description -- -- ComboLBox The class for the list box contained in a combo box. DDEMLEvent Windows NT/Windows 2000/Windows XP: The class for Dynamic Data Exchange Management Library (DDEML) events. MessageWindows 2000/Windows XP: The class for a message-only window. #32768 The class for a menu. #32769 The class for the desktop window. #32770 The class for a dialog box. #32771 The class for the task switch window. #32772 Windows NT/Windows 2000/Windows XP: The class for icon titles.
Re: TaxCut and C++ exception handling
Ori Pessach wrote: No - I get the goal of the project. What I'm not clear about is where to draw the line between system components and application components. Is msvcrt.dll shipped with Windows, or with Windows applications? It does come with recent Windows. However, many programs install an updated version of msvcrt.dll, since it is a redistributable for Microsoft Visual Studio 5 and 6. Visual Studio 7 has switched to msvcr70.dll et. al. As of Windows XP, msvcrt.dll is part of the operating system. It is now under system file protection, so it cannot be replaced by a normal application. Apparently as a tribute to this, they changed the description from Microsoft (R) C Runtime Library to Windows NT CRT DLL. Some programs that don't depend on having fixes in a certain version of msvcrt.dll will depend on the version from Windows; this includes most programs developed with VC6 specifically for Windows XP, and all programs developed with recent versions of the MinGW Win32 port of GCC. Therefore, we really do need a complete msvcrt.dll in Wine.
Re: dlls/comcat Makefile.in version.rc include/wine wine_common_ver.rc
Changelog: John K. Hohm [EMAIL PROTECTED] Added optional OLESelfRegister to wine_common_ver.rc, used in dlls/comcat. This apparently was not applied; was it flawed, or simply missed?
Re: Problem compiling current CVS on Redhat 8
wine/dlls/comcat/: comcat_private.h:45: conflicting types for `ClassFactoryImpl' comcat.h:49: previous declaration of `ClassFactoryImpl' [more of same error for ther types] I'm quite confused by this; the current comcat.h only has 34 lines, and doesn't define ClassFactoryImpl. I also get this: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__ -D_REENTRANT -o comcat_main.o comcat_main.c In file included from comcat.h:28, from comcat_private.h:29, from comcat_main.c:21: .../../include/wine/obj_base.h:26:2: #error DO NOT INCLUDE DIRECTLY The current comcat.h doesn't include obj_base.h. Are you certain you have the latest from CVS? You can see it here: http://cvs.winehq.com/cvsweb/wine/include/comcat.h?rev=1.7content-type=text/x-cvsweb-markup
Re: wine/dlls/comcat regsvr.c comcat_main.c
Quoting Dimitrie O. Paun [EMAIL PROTECTED]:
On January 10, 2003 12:48 am, John K. Hohm wrote:
+CLSID const *clsid;/* NULL for end of list */
[...]
+{ NULL } /* list terminator */
Why not terminate the list with a NULL pointer to the struct instead,
it's simpler and more idiomatic...
It is because I am using a list of structures, not a list of pointers to
structures. How would you create a static list of pointers to structures,
without naming each one?
Re: Help with /?? stuff
Alberto Massari wrote: I guess Wine is converting the NULL into \?? to be able to store it as a string. Shachar Shemesh wrote: You guessed wrong. The leading \?? is there under both Wine and Windows 2000, and in both cases there is ALSO a NULL. As neither Wine nor Windows 2000 then accepts that as a valid path, I'll just remove it. I was just wondering whether anyone knows why Windows 2000 puts that extra stuff in (it's obvious why wine does that - to be compatible). I'm not sure about \??, but see this excerpt from MSDN Re CreateFile: lpFileName [in] Pointer to a null-terminated string that specifies the name of the object to create or open. In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend \\?\ to the path. For more information, see Naming a File. Windows 95/98/Me: This string must not exceed MAX_PATH characters.
Re: Registering DLL's
Quoting Alexandre Julliard [EMAIL PROTECTED]: That's much better than the previous one. I'm not convinced you really need to build a static list, you might as well have a function to register a single interface and call it a number of times. The main reason I used a static list was to make it impossible to forget to unregister one of the interfaces you registered; that is why the unregister functions take the entire structures (but only need the first members). OTOH, if we might someday want to avoid unregistering one or more interfaces or classes we registered, having separate functions would make that easier. I think I still prefer the structures, but are you convinced enough? I'm afraid copying it is the best choice; I don't think we want a new dll for just a couple of routines. It's not very elegant to duplicate it, but it shouldn't be a lot of code anyway. What would it take to make a static library work for this? Unlike a dll, that would not have any overhead, would it? I'm a real sucker for elegance, you know. :-) I used to think any library, even a static one, had to have a certain amount of bloat, until I came across the dietlibc (http://www.fefe.de/dietlibc/).
Re: Registering DLL's
What would it take to make a static library work for this? Unlike a dll, that would not have any overhead, would it? I'm a real sucker for elegance, you know. :-) It's possible, but it adds quite a bit of complexity to the build process, and creates annoying dll dependencies. I'd prefer that we start with the duplication for now, and see how ugly it gets. Okay, we'll start with the duplication. :-| When I prepare a patch including the shared regsvr.h and regsvr.c, should I include them everywhere they're needed (repeating them in the patch multiple times), or just add a note like Hey Alexandre, do a cp regsvr.[hc] ..., or maybe should I always submit the changes as separate patches for each dll?
Re: Registering DLL's
Quoting Alexandre Julliard [EMAIL PROTECTED]: Please do it in one dll only for now and submit that; once it's tested and integrated we can start copying it around. Also I'd suggest Okay. Should I perhaps start with something better-used than comcat (perhaps ole32) so that testing will be likely to fail quickly if it's broken? putting the Dll(Un)RegisterServer functions in the same .c file so that you don't need a .h at all, this way there will be less duplication. Are you suggesting that the static data defining which classes and interfaces to register be located in the same file as the implementation of the (un)registration functions? That would make copying the implementation around even more work, since I couldn't just copy regsvr.[hc] and keep the differing data in the respective dll-specific sources. I suppose you could also mean that *only* the static data be stored in a dll- specific file, with predefined variable names to be found by the regsvr.c, but that still requires a regsvr.h to get the struct definitions.
Re: Registering DLL's
On Wed, Dec 04, 2002 at 05:14:23PM -0800, Alexandre Julliard wrote:
John K. Hohm [EMAIL PROTECTED] writes:
I posted my idea for representing the registration data, accidentally from
[EMAIL PROTECTED] rather than my usual [EMAIL PROTECTED] (see
http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html), but I haven't
gotten any responses, not even looks fine or you are a moron. I guess I'll
just start submitting patches, then.
Sorry, I must have missed that one. I don't really like the ASCII
description of the registry keys; I think it would be better to do it
at a more symbolic level. For instance you shouldn't hardcode the
ASCII form of the CLSID, you should have some kind of register CLSID
function that takes a CLSID and uses StringFromCLSID or whatever to
create the corresponding registry key.
The types of things that a COM server DLL is likely to register are fairly
limited; essentially just classes and interfaces. I have come up with
a different interface, that accepts a list of structures more closely
matching the requirements of registering and unregistering a COM server.
This is the interface in regsvr.h for use by Dll[Un]RegisterServer:
struct regsvr_interface
{
IID const *iid; /* NULL for end of list */
LPCSTR name;/* can be NULL to omit */
IID const *base_iid;/* can be NULL to omit */
int num_methods;/* can be 0 to omit */
CLSID const *ps_clsid; /* can be NULL to omit */
CLSID const *ps_clsid32;/* can be NULL to omit */
};
HRESULT register_interfaces(struct regsvr_interface const *list);
HRESULT unregister_interfaces(struct regsvr_interface const *list);
struct regsvr_coclass
{
CLSID const *clsid; /* NULL for end of list */
LPCSTR name;/* can be NULL to omit */
LPCSTR ips; /* can be NULL to omit */
LPCSTR ips32; /* can be NULL to omit */
LPCSTR ips32_tmodel;/* can be NULL to omit */
};
HRESULT register_coclasses(struct regsvr_coclass const *list);
HRESULT unregister_coclasses(struct regsvr_coclass const *list);
Here is an example of its use in comcat_main.c; this is admittedly much
less than would appear on ole32_main.c, but everything required there
should be included in the structures:
static struct regsvr_coclass coclass_list[] = {
{ CLSID_StdComponentCategoriesMgr,
StdComponentCategoriesMgr,
NULL,
comcat.dll,
Both
},
{ NULL }/* list terminator */
};
HRESULT WINAPI COMCAT_DllRegisterServer()
{
TRACE(\n);
return register_coclasses(coclass_list);
}
HRESULT WINAPI COMCAT_DllUnregisterServer()
{
TRACE(\n);
return unregister_coclasses(coclass_list);
}
Alexandre, feel free to disapprove of this interface also; most of my
experience writing interfaces to library pieces has either been big, complex
Automation stuff to support VB database apps, or object-oriented C++.
I would also like suggestions on whether an interface like this should
be exported via a static library like libwine_unicode.a (can that work
when I call advapi32 exports?), via a new wine-specific dll in src/dlls,
or simply by copying the implementation around to all the COM server dlls
(my least favorite option).
--
John Hohm [EMAIL PROTECTED]
I once had sufficient wisdom to value an absent .sig over a lame one.
Re: Registering DLL's
Alexandre said: Part of it should be done with DllRegisterServer, the rest can be handled by the .inf script. And I think it's OK to add the necessary DllRegisterServer entry points even if the native dll doesn't have them. I'm glad you feel that way. I created bug 1117, Make all Wine OLE DLLs self-registerable, and have been working on an implementation. For some reason I can't accept the bug; though I've tried several times, it stays at UNCONFIRMED. What to do about DLLs like ole32.dll that have a native DllRegisterServer but no corresponding DllUnregisterServer? I'm inclined to include it for completeness, though it's unlikely that anyone would ever want to unregister such a basic system DLL. I posted my idea for representing the registration data, accidentally from [EMAIL PROTECTED] rather than my usual [EMAIL PROTECTED] (see http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html), but I haven't gotten any responses, not even looks fine or you are a moron. I guess I'll just start submitting patches, then.
self-registerable COM server dlls
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---C000-0046}\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
Re: Page fault with isspace(*p)
On Fri, 22 Nov 2002, John K. Hohm wrote:
static int getc_skipws(char const **p)
{
while (isspace(*p))
++*p;
return **p;
}
Sometimes you just need to ask a question in order for the answer to
become obvious. **p == '[', but *p == a char const*, duh.
Page fault with isspace(*p)
I am rewriting the regsvr stuff in dlls/comcat to make it practical to
extend to ole32 and all the other COM DLLs. I have a nice simple function
to skip whitespace and return the next character:
static int getc_skipws(char const **p)
{
while (isspace(*p))
++*p;
return **p;
}
This gets called with **p == '['. I get a page fault in the
implementation of isspace(), where the macro is testing 0x20 against the
value for '[' in the __ctype_b array. What gives?
Re: COM Enhancement patch
Well, I was hoping some of the COM experts would comment on that. If I understand it right you are avoiding writing some thunking routines for older interfaces, at the cost of an extra pointer access in every function. I'm not convinced it's a good trade-off, but I'd like to hear other opinions. I might not exactly be an expert, but I don't like the extra work being done everywhere with the extra pointer. If writing the thunk functions is really so cumbersome, perhaps a macro for generating the thunk functions is in order.
Re: WineSetupTk
First off, thanks for the offer -- it's generous, and very useful IMO. It certainly sounds interesting, and I would like to take a peak at the code. The big problem I have with WineSetupTk it's that it's written in Tcl/Tk (I suppose). I don't know the language, and I don't care to learn it. Moreover, I think Wine should use itself for such tools, so we get to use all the nice controls we have g. One thing that I'd like to see is a programs/winesetup utility that's based on WineSetupTk, but it's written in C, with the Win32 API Controls. I believe Alexandre plans to have Wine configured via the registry eventually. Then it would probably make sense to have a C program that acted as a control panel applet and did what WineSetupTk does, but in a dynamic fashion using the registry APIs. Until then I would expect a C version of WineSetupTk to be rather ugly from having to deal with much text config parsing and manipulation.
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
Quoting John K. Hohm [EMAIL PROTECTED]: No, it's wrong. You should be using the Windows API (CreateProcess etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. Sorry, I had a few beers tonight ;) Ok, I just remembered what my concerns were about using CreateProcess initially when I looked at MSDN: I think you need to look more closely at the LPSTARTUPINFO lpStartupInfo argument to CreateProcess. It points to a STARTUPINFO structure having HANDLE hStdInput, HANDLE hStdOutput, and HANDLE hStdError members, which are used if the dwFlags member has the STARTF_USESTDHANDLES bit set. I'm a little wonky today too, I sent it to pudexo.org first. :-/
Re: So lets say we do it
Once we have that we need to make sure we have suitable defaults to allow running at least the drives/paths control panel without registry files at all. We also need the Wine dlls to register themselves instead of having to merge winedefault.reg by hand. Then it should be possible to write a .inf script to setup a new Wine install automatically from scratch. Once upon a time (well okay, in July) I said I would make the Wine dlls self-registerable, and now I've gone and created bug #1117 to remind me to do it. I plan to use the (mostly-)static-array-driven, dumb but generic, regsvr_register and regsvr_unregister functions that are currently situated in dlls/comcat. I don't like the idea of copying around exact duplicates of regsvr.[hc], but they seem too small to put in their own libwine_regsvr.so; what do you recommend?
Re: interrupts in when in NT version
Tough all safedisc programs depend on this, I have decided not to make an official patch. The reason is that additional info is needed for a proper fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an int 0x01 call. But it should be checked what exceptions are raised on different windows versions when int 0x01 is called. And maybe the same should be done with other interrupts. It would be good if somebody could make that test program. Else I will keep the non proper fix. You may think me a rube, but I just made a test program that calls an arbitrary interrupt and prints the exception information. I don't set up any registers, so perhaps it generates an exception when it ought not in some cases, but anyone else is free to improve it. Source and a VC6-compiled MSVCRT-using version, along with results for all 255 interrupts on Windows XP Professional, is here: http://petra.trnty.edu/~jhohm/intexcep.zip
Impressive success
I just got an ATAPI Plextor PlexWriter 40/12/40A (which rocks), and Plextor's Win32-only firmware updater worked flawlessly in wine, a few months old CVS. Kudos to all involved in supporting that sort of access!
Re: FYI
Thus spake Eric Pouech [EMAIL PROTECTED]: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmglp.asp didn't read it yet, but could be an interesting introduction for new Wine developpers I got a kick out of the two graphs in chapter 2; one shows increasing Windows versions going up and right with time increasing to the right, the other shows Unix versions going down with time increasing downwards. No subtle clues there, right?
Re: thread confusion
Thus spake Bill Medland: [...] I added a couple of MessageBox calls in the source of the control's code. While the OCX was loading the before and after message boxes were displayed as expected. However once the OCX was up and I pulled down the dropdown list the before message box popped up TWICE and you had to say OK to them in the correct order to get the pair of after boxes. So I included GetCurrentThreadID in the message they displayed, thinking that we now had two threads. But both had (or appeared to have) the same thread ID. So I turned on the dialog warnings and, yes, the second call to MessageBox was occurring while the first was still executing. Anyone know what is going on there? I suspect you are calling MessageBox() during processing of a message sent via SendMessage() during processing of another message posted to the control's queue. That is typically a recipe for confusion or worse; one way to avoid it, though it might not make MessageBox() debugging very useful, is to call MessageBox() only when InSendMessage() returns FALSE.
Re: OLE classes registration
Quoting Andriy Palamarchuk [EMAIL PROTECTED]: --- John K. Hohm [EMAIL PROTECTED] wrote: [skipped] I wrote the regsvr.[hc] in dlls/comcat with the intent of their being useful for other dlls' self-registration. It should be possible to copy regsvr.h and regsvr.c, tweak the implementations of DllRegisterServer and DllUnregisterServer, and write the appropriate regsvr structure definitions, and have made another dll self-registerable. I would be willing to do that myself for other dlls if those responsible for them ask nicely. :-) John, as this is not implemented yet I think it still has sense for me to add the OLE classes registration entries to the default registry file. The default registry value can be removed later when dlls registration is implemented. I agree. After all, there is not yet a way for dlls that are already self- registerable to automatically get registered when installing Wine. Also, I can benefit from your work in finding the correct registry entries when I do implement self-registration.
Re: OLE classes registration
Andriy Palamarchuk [EMAIL PROTECTED] wrote: --- Steven Edwards [EMAIL PROTECTED] wrote: I dont know very much about ole or COM so if I am way wrong just flame me. =) Can the regsvr code from comcat be adapted for this? Rather then implementing more stuff in winedefaultreg can we make all of the OLE/COM stuff self-register? I think during on of my tests on windows with the wine dlls that was a problem I encountered and at least for comcat it is now fixed. Yes, as was discussed before this is the right way to do it. Anyway, finding out what information to add and and development of the dlls registering process are pretty much independent from each other. I wrote the regsvr.[hc] in dlls/comcat with the intent of their being useful for other dlls' self-registration. It should be possible to copy regsvr.h and regsvr.c, tweak the implementations of DllRegisterServer and DllUnregisterServer, and write the appropriate regsvr structure definitions, and have made another dll self-registerable. I would be willing to do that myself for other dlls if those responsible for them ask nicely. :-) This reminds me that a self-registerable dll is supposed to have a VS_VERSION_INFO resource, with an empty OLESelfRegister value in the StringFileInfo block. comcat.dll has no resources; is there a standard Wine way to add such version info?
Re: CxxFrameHandler problem
Alexandre Julliard [EMAIL PROTECTED] wrote: Uwe Bonnes [EMAIL PROTECTED] writes: Appended program uses CxxFrameHandler and crashes in wine with builtin msvcrt, but not with native. Compile as Release version and include the MFC dll. Can somebody compile for Alexandre? Alexandre, is this a start or do you need something complete? That's a start, yes, thanks. I'll need a more complete example with nested try blocks, destructors all over the place, typed exceptions, etc. to make sure I understand all the compiler internal structures; but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?
Re: self-registerable standard DLLs
Quoting Tony Lambregts [EMAIL PROTECTED]: which should suffice for normal Wine installations. Despite this, is it generally acceptable to have actual code to register/unregister a standard COM server DLL in its Dll[Un]RegisterServer? It would be redundant for normal Wine, but hey, it's not big or complex. Actually putting that in DllRegisterServer is arguably the right way to do it. What we should have is some kind of installation step that would register the Wine dlls, instead of having to put everything in winedefault.reg. Would it be a good idea to create a bug report for this?... Or does someone want to implement it right away... I was just about ready to send the last patch to complete the comcat.dll implementation, fixing bug 652. I don't think another bug is necessary; I'll implement Dll[Un]RegisterServer before pronouncing the bug fixed. Hopefully doing this in the next couple of days will be right away enough for you. ;-)
self-registerable standard DLLs
I noticed that the attempt to test comcat.dll on Win98 failed because DllRegisterServer is a stub returning E_NOTIMPL. I have added the registry entries for the component categories manager to winedefault.reg, which should suffice for normal Wine installations. Despite this, is it generally acceptable to have actual code to register/unregister a standard COM server DLL in its Dll[Un]RegisterServer? It would be redundant for normal Wine, but hey, it's not big or complex.
Re: Part 1 - Mingw Port Status 5-20-02
Builds with easy fix - comcat.dll (needs msvcrt import due to swprintf usage) I would rather not have comcat.dll import msvcrt.dll, as ntdll.dll exports swprintf even on Windows NT.
nasty NTDLL_vsnwprintf bug?!?
My heap corruption problem turned out to be a bug in swprintf (well,
really in NTDLL_vsnwprintf), I think. I tried formatting like this:
WCHAR keyname[21] = { 'C', 'o', 'm', 'p', 'o', 'n', 'e', 'n',
't', ' ', 'C', 'a', 't', 'e', 'g', 'o',
'r', 'i', 'e', 's', 0 };
WCHAR fmt[4] = { '%', 'l', 'X', 0 };
swprintf(This-xlcid, fmt, lcid);
My poor little WCHAR xlcid[9] member of This was seriously overflowed by
the string L409Component Categories. The following patch fixes what
appears to be a format reading bug in NTDLL_vsnwprintf. I didn't just
send it to wine-patches because it's not my area and it seems unlikely
such a bad bug could hang around in such a function. Then again, I don't
see many uses of swprintf in the source; should I be using something
better for sprintf's of WCHAR's?
--- dlls/ntdll/wcstring.c.~1.15.~ Thu May 16 19:59:27 2002
+++ dlls/ntdll/wcstring.c Fri May 17 23:09:21 2002
-451,10 +451,7
}
if (*iter == (WCHAR)L'h' ||
*iter == (WCHAR)L'l')
- {
*fmta++ = *iter++;
- *fmta++ = *iter++;
- }
switch (*iter)
{
err:heap:HEAP_ValidateInUseArena
I am implementing a COM object in comcat.dll that allocates itself with
HeapAlloc and frees itself on its last Release with HeapFree. I am using
it in a simple test program that creates it and releases it, and when the
Release happens I get this:
err:heap:HEAP_ValidateInUseArena Heap 4034: in-use arena 40378878 next
block has PREV_FREE flag
It seems to be saying that I'm freeing an already-free block. I ran the
test program with --debugmsg trace+all, and I can see that the only uses
of the heap during the lifetime of my object instance are one
ntdll.RtlAllocateHeap that returns 40378880, and one ntdll.RtlFreeHeap
that gets 40378880 as its third param. The RtlFreeHeap is immediately
followed by the err:heap, which then spits out a bunch of heap info. It
seems pretty obvious that I'm freeing the block of memory I had just
allocated; what else might be causing the err:heap?
Here is the interesting section of the trace:
080701d0:trace:ole:COMCAT_ICatInformation_EnumCategories
080701d0:Call ntdll.RtlAllocateHeap(4034,0008,0020) ret=4397c0f3
080701d0:trace:heap:RtlAllocateHeap (4034,000a,0020): returning 40378880
080701d0:Ret ntdll.RtlAllocateHeap() retval=40378880 ret=4397c0f3
080701d0:trace:ntdll:NTDLL_vsnwprintf (2147483647,L%lX)
080701d0:Call advapi32.RegOpenKeyExW(8000,40566ce8 LComponent
Categories,,00020019,40378898) ret=4397c170
080701d0:Call ntdll.RtlInitUnicodeString(40566bd8,40566ce8 LComponent Categories)
ret=40660189
080701d0:Ret ntdll.RtlInitUnicodeString() retval=002a ret=40660189
080701d0:Call ntdll.NtOpenKey(40378898,00020019,40566be0) ret=40660194
080701d0:trace:reg:NtOpenKey (0x8000,LComponent Categories,20019,0x40378898)
080701d0: open_key( parent=-2147483648, access=00020019, name=LComponent Categories )
Open key ERROR
080701d0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 }
080701d0:trace:reg:NtOpenKey - 0x
080701d0:Ret ntdll.NtOpenKey() retval=c034 ret=40660194
080701d0:Call ntdll.RtlNtStatusToDosError(c034) ret=4066019a
080701d0:Ret ntdll.RtlNtStatusToDosError() retval=0002 ret=4066019a
080701d0:Ret advapi32.RegOpenKeyExW() retval=0002 ret=4397c170
080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_AddRef
080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Next
080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Release
080701d0:Call ntdll.RtlFreeHeap(4034,,40378880) ret=4397be9d
080701d0:err:heap:HEAP_ValidateInUseArena Heap 4034: in-use arena 40378878 next
block has PREV_FREE flag
The Component Categories Manager
I have been playing with getting a large application made with VB6 and using many third-party ActiveX controls to work with Wine. I am currently having a problem with the absence of COMCAT.DLL and The Component Categories Manager which is ostensibly implemented in it. In fact, Windows implements it in OLE32.DLL; COMCAT.DLL has do-nothing stubs for the registration functions and forwards DllGetClassObject to OLE32.DLL. The MSDN documentation for The Component Categories Manager seems very straightforward; it documents ICatRegister and ICatInformation, which I believe I could implement. Since I've not contributed to Wine before, and just recently joined the digested list, I want to check the following things: * Is anyone else working on this at the moment? * Is there a major technical reason this can't be done yet? * Is there some other reason for me not to work on this soon? * How should the source for this new functionality be organized? * Is there a standard (or exemplary) way to implement IEnum? I'll be needing IEnumCATID, IEnumCLSID, and IEnumCATEGORYINFO. * What should I do when I think I have working code?
