Re: tips needed for implementing the common control ICC_STANDARD_CLASSES
Ok I'll try to get that in. Thanks for the tip Juan. On Sat, 28 Aug 2004 22:26:22 -0700 (PDT), Juan Lang <[EMAIL PROTECTED]> wrote: > James wrote: > > The unknown class is one of the two control classes > > left to be implemented in commctrl: > > ICC_STANDARD_CLASSES. I would like to implement > > this class, but I have no idea where to start. > > It doesn't look like you'd need to do anything special > for the ICC_STANDARD_CLASSES case. The standard > controls are all registered when user32 loads (see the > call to CLASS_RegisterBuiltinClasses in user32's > user_main.c). Comctl32 already imports user32, so > ICC_STANDARD_CLASSES ought to be able to be added to > the /* dummy initialization */ section of > InitCommonControlsEx. > > While you're at it, the comment appears to be > incorrect. It says ICC_LINK_CLASS is unimplemented, > but in fact it is in the case statement below. The > comment at the top of the file is similarly out of > date. > > At least, that's what I get by reading it. YMMV. Try > patching and seeing how kazaa lite does :) > > --Juan > > > __ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail > -- James Hawkins
Re: tips needed for implementing the common control ICC_STANDARD_CLASSES
James wrote: > The unknown class is one of the two control classes > left to be implemented in commctrl: > ICC_STANDARD_CLASSES. I would like to implement > this class, but I have no idea where to start. It doesn't look like you'd need to do anything special for the ICC_STANDARD_CLASSES case. The standard controls are all registered when user32 loads (see the call to CLASS_RegisterBuiltinClasses in user32's user_main.c). Comctl32 already imports user32, so ICC_STANDARD_CLASSES ought to be able to be added to the /* dummy initialization */ section of InitCommonControlsEx. While you're at it, the comment appears to be incorrect. It says ICC_LINK_CLASS is unimplemented, but in fact it is in the case statement below. The comment at the top of the file is similarly out of date. At least, that's what I get by reading it. YMMV. Try patching and seeing how kazaa lite does :) --Juan __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Re: working together on stdole.tlb and a end to dcom9x
On Sun, Aug 29, 2004 at 04:42:04AM +0200, Filip Navara wrote: > > You're pretty much right. I tried to create *very* simple > HelloWorld-type type library with it and and it reported me bunch of > "stub!" messages and crashed. I also found a bug in implementation of > ITypeLib2_fnGetTypeInfoOfGuid (in fact both implementations, the one in > typelib.c and the second in typelib2.c). It should reference the typelib > it's called on. This ensures that later call > ITypeInfo_GetContainingTypeLib will not return bogus pointer if the > original caller already released the TypeLib. See the attached test. If > any COM hacker around can fix it, it would be nice. You're right to be suspicious, and there may actually be a bug with the reference counting in typelib2.c, but fnGetTypeInfoOfGuid should -not- directly AddRef() the containing typelib. Such an AddRef() rightfully belongs in with the implemetations of QueryInterface(), AddRef(), and Release() on ICreateTypeInfo2. It is supposed to be set up that the TypeInfo objects never deallocate themselves when they hit 0 references, but they do hold a reference to their containing typelib. The TypeLib objects never hold a reference to any of their typeinfos (so as not to cause a reference cycle), but they are set up to deallocate the typeinfo structures when the typelib hits 0 references. I'll give the typelib2.c code a look-over tomorrow with an eye towards verifying that reference counting is correct. > Regards, > Filip --Alastair Bridgewater
Re: tips needed for implementing the common control ICC_STANDARD_CLASSES
> This is all just speculation, but maybe it's possible that Kazaa uses a > non-standard control in it's code? You could be right about this, but I'm pretty sure it's ICC_STANDARD_CLASSES that's needed, because the error I get when I try to run wine is: fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 I looked through wine/include and in commctrl.h we have: ICC_STANDARD_CLASSES 0x4000 and in dlls/comctrl32/commctrl.c we have: * FIXME * implement the following control classes: * ICC_LINK_CLASS * ICC_STANDARD_CLASSES in the docs of InitCommonControlsEx. > By without native dlls, are you referring to without all standard > windows dlls, (meaning you can use the dlls supplied with kazaa lite) or > without all dlls, period, end of story? Yea if kazaa gives us dlls to use...we'll use em. On Sat, 28 Aug 2004 22:17:24 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Fri, Aug 27, 2004 at 12:53:36PM -0400, James Hawkins wrote: > > I'm reading through msdn some more and they say ICC_STANDARD_CLASSES should > > > > "Load one of the intrinsic User32 control classes. The user controls > > include button, edit, static, listbox, combobox, and scrollbar." > > > > If I'm remembering, those controls are already implemented in > > wine/controls. Maybe ICC_STANDARD_CLASSES just loads one/several of > > these controls for the user. I'm really not sure though, and I'm sure > > This is all just speculation, but maybe it's possible that Kazaa uses a > non-standard control in it's code? That wouldn't surprise me, > especially when one considers the complex peer-to-peer concepts behind > how it works. > > > someone on wine-devel knows a lot more about this than me. > > ditto, probably. > > > On Fri, 27 Aug 2004 12:48:03 -0400, James Hawkins <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I've had a lot of people ask me about how well kazaa lite runs in > > > wine, so I will be working on getting it to work. The install file is > > > called klitekpp243e.exe, and the setup works great. (NOTE: im trying > > > to get the app to work without having to use any native dlls) After > > By without native dlls, are you referring to without all standard > windows dlls, (meaning you can use the dlls supplied with kazaa lite) or > without all dlls, period, end of story? The former should be easier, > right? > > > > > > the installation of klite, a program called KLConfigWizard.exe is run. > > > It's a dialog box with some text initially, then when you click the > > > next button, the user encounters a fatal error and we're sent to the > > > debugger. The error is: > > > > > > fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 > > > > > > The unknown class is one of the two control classes left to be > > > implemented in commctrl: ICC_STANDARD_CLASSES. I would like to > > > implement this class, but I have no idea where to start. I've > > > searched msdn for ICC_STANDARD_CLASSES, but it only turned up a link > > > to the INITCOMMONCONTROLSEX structure. If anyone has any ideas or > > > hints that they can give me, I would really appreciate it. Thanks for > > > your time. > > > > > > -- > > > James Hawkins > > > > > > > > > -- > > James Hawkins > > > -- James Hawkins
Re: working together on stdole.tlb and a end to dcom9x
Nyef wrote:
The ICreateTypeLib2 interface is used to create the new-style MSFT typelibs.
The older ICreateTypeLib interface is used for the old-style typelibs. While
the newer interface also implements the older one, when you ask for the old
interface with CreateTypeLib() you get a completely different implementation.
Ok, I studied the code more and now I understand the the difference
(SLTG vs. MSFT libraries). Thanks for explaining.
I don't see why it necessarily follows that stdole32 wouldn't work as an MSFT
typelib, but the implementation of ICreateTypeInfo2 is badly incomplete in
places, and I would trust it to completely mess up any semi-complex type
library you attempt to create with it. Specifically, any type library that
involves functions or variables.
You're pretty much right. I tried to create *very* simple
HelloWorld-type type library with it and and it reported me bunch of
"stub!" messages and crashed. I also found a bug in implementation of
ITypeLib2_fnGetTypeInfoOfGuid (in fact both implementations, the one in
typelib.c and the second in typelib2.c). It should reference the typelib
it's called on. This ensures that later call
ITypeInfo_GetContainingTypeLib will not return bogus pointer if the
original caller already released the TypeLib. See the attached test. If
any COM hacker around can fix it, it would be nice.
Regards,
Filip
#include
#include
#include
#define ok(x,y) if (!(x)) printf(y); else printf("ok\n")
int main()
{
LPTYPELIB ptlibStdOle;
LPTYPEINFO ptinfoIUnknown;
HRESULT result;
result = LoadTypeLib(OLESTR("stdole32.tlb"), &ptlibStdOle);
ok(result == S_OK, "can't load stdole32.tlb");
/* continue only if stdole32.tlb is present. */
if (result == S_OK)
{
ok(ptlibStdOle->AddRef() == 2, "invalid reference count\n");
/* GetTypeInfoOfGuid adds refernece to typelib */
result = ptlibStdOle->GetTypeInfoOfGuid(IID_IUnknown, &ptinfoIUnknown);
ok(result == S_OK, "can't get type info about IUnknown");
ok(ptlibStdOle->Release() == 2, "invalid reference count\n");
ok(ptinfoIUnknown->Release() == 0, "invalid reference count\n");
ok(ptlibStdOle->Release() == 0, "invalid reference count\n");
}
}
Re: tips needed for implementing the common control ICC_STANDARD_CLASSES
On Fri, Aug 27, 2004 at 12:53:36PM -0400, James Hawkins wrote: > I'm reading through msdn some more and they say ICC_STANDARD_CLASSES should > > "Load one of the intrinsic User32 control classes. The user controls > include button, edit, static, listbox, combobox, and scrollbar." > > If I'm remembering, those controls are already implemented in > wine/controls. Maybe ICC_STANDARD_CLASSES just loads one/several of > these controls for the user. I'm really not sure though, and I'm sure This is all just speculation, but maybe it's possible that Kazaa uses a non-standard control in it's code? That wouldn't surprise me, especially when one considers the complex peer-to-peer concepts behind how it works. > someone on wine-devel knows a lot more about this than me. ditto, probably. > On Fri, 27 Aug 2004 12:48:03 -0400, James Hawkins <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I've had a lot of people ask me about how well kazaa lite runs in > > wine, so I will be working on getting it to work. The install file is > > called klitekpp243e.exe, and the setup works great. (NOTE: im trying > > to get the app to work without having to use any native dlls) After By without native dlls, are you referring to without all standard windows dlls, (meaning you can use the dlls supplied with kazaa lite) or without all dlls, period, end of story? The former should be easier, right? > > the installation of klite, a program called KLConfigWizard.exe is run. > > It's a dialog box with some text initially, then when you click the > > next button, the user encounters a fatal error and we're sent to the > > debugger. The error is: > > > > fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 > > > > The unknown class is one of the two control classes left to be > > implemented in commctrl: ICC_STANDARD_CLASSES. I would like to > > implement this class, but I have no idea where to start. I've > > searched msdn for ICC_STANDARD_CLASSES, but it only turned up a link > > to the INITCOMMONCONTROLSEX structure. If anyone has any ideas or > > hints that they can give me, I would really appreciate it. Thanks for > > your time. > > > > -- > > James Hawkins > > > > > -- > James Hawkins >
Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
On Sat, Aug 28, 2004 at 01:54:19AM +1000, Con Kolivas wrote: > Mike Hearn wrote: > >>>Well, apparently we don't use sched_yield, so the problem must > lie somewhere else. Maybe Con can help us out here? Alexandre says he > >> > >>Interesting. Probably the most valuable information is that it seems > >>to work fine if we artificially limit the threads to exactly the same > >>timeslice _or_ we put them at such a low priority that they are forced > >>to be guaranteed to round robin one task at a time. This is the way > >>2.4 used to work which is why with the new 2.6 schedulers which do far > >>more out-of-order rescheduling some applications have a problem; > >>particularly under load. I suspect it's actually the latter issue. > >>Locking between threads should prevent that being a problem, though. > >>You already mentioned that you dont use sched_yield() and I couldn't > >>even begin to look at the wine code myself so perhaps you know > >>something more. > > > > > >Hi Con, > > > >One thought that occurred to me, and this is just a random theory, is > >that maybe the issue is not with the Wine code but the Win32 code run on > >top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows > >(NT) scheduling? Could it be that some apps are written to expect > >Windows-style scheduling and fail to work if they don't get it? > > I argued with myself about the logic in this for ages. The best I could > come up with is - I don't know :| I'd need to know about windows > scheduling (which I don't) Obviously, if Win apps have been written to expect this, there's documentation somewhere... if someone has free time, maybe look for it? IIRC, there are some things about priority scheduling, and that apps take complete control of the CPU for a set period of time based on that priority (something like Very High, High, Normal, Low, Very Low or something in the eyes of a consumer) -- which leads to the behaviour that CPU intensive apps which have high priority slow down the PC and take up loads of CPU time, and poorly written apps that have high priority can loop forever, and crash/freeze the PC because other apps don't get CPU time, nor does the interrupter (Ctrl-Alt-Del and it's Task Manager (which IIRC worked better in 9x by taking over and halting all processes but itself, but had more features and became an app like everything else in later versions)). Unfortunately, this is all speculation, because I am a 9x user with some experience with XP machines, not a Windows Developer. > and how wine treats that scheduling (which I also don't). Can someone explain where this is written, or why it isn't? > > Cheers, > Con Just a curious onlooker, --Michael Chang
Re: working together on stdole.tlb and a end to dcom9x
On Sat, Aug 28, 2004 at 11:06:46PM +0200, Filip Navara wrote: > Mike Hearn wrote: > > >It basically involves implementing the ICreateTypeLib interfaces in our > >OLE dlls. Nyef did some great work on this but for stdole32.tlb we need > >the other version, I think. > > > > > Can you elaborate more please? Looking at dlls/oleaut32/typelib2.c I see > that the ICreateTypeLib2 interface is implemented. The ICreateTypeLib2 interface is used to create the new-style MSFT typelibs. The older ICreateTypeLib interface is used for the old-style typelibs. While the newer interface also implements the older one, when you ask for the old interface with CreateTypeLib() you get a completely different implementation. I don't see why it necessarily follows that stdole32 wouldn't work as an MSFT typelib, but the implementation of ICreateTypeInfo2 is badly incomplete in places, and I would trust it to completely mess up any semi-complex type library you attempt to create with it. Specifically, any type library that involves functions or variables. > Regards, > Filip --Alastair Bridgewater
Re: working together on stdole.tlb and a end to dcom9x
Mike Hearn wrote:
It basically involves implementing the ICreateTypeLib interfaces in our
OLE dlls. Nyef did some great work on this but for stdole32.tlb we need
the other version, I think.
Can you elaborate more please? Looking at dlls/oleaut32/typelib2.c I see
that the ICreateTypeLib2 interface is implemented.
Regards,
Filip
--- dlls/oleaut32/typelib.c Thu May 13 13:47:56 2004
+++ dlls/oleaut32/typelib.c Sat Aug 28 21:04:19 2004
@@ -246,8 +246,8 @@
HRESULT WINAPI CreateTypeLib(
SYSKIND syskind, LPCOLESTR szFile, ICreateTypeLib** ppctlib
) {
-FIXME("(%d,%s,%p), stub!\n",syskind,debugstr_w(szFile),ppctlib);
-return E_FAIL;
+TRACE("(%d,%s,%p)\n",syskind,debugstr_w(szFile),ppctlib);
+return CreateTypeLib2(syskind, szFile, (ICreateTypeLib2**)ppctlib);
}
/**
* LoadTypeLib [OLEAUT32.161]
cleanup w->a cross calls in printdrv
I want to send this through wine-devel first to see if there are any
problems with it. In gdi_private.h I had to change the parameters
that pStartDoc accepted from DOCINFOA to DOCINFOW. I know I shouldn't
change public api headers, but this one is private so the change seems
acceptable. If it's not let me know. Another problem that might
popup is the way the DOCINFOW struct is filled in the StartDocA
function:
len = MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, NULL, 0 );
docName = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) );
MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, docName, len );
docW.lpszDocName = docName; <--- is this assignment a problem?
if(docName)
HeapFree( GetProcessHeap(), 0, (LPWSTR)docName );
The reason why I had to make a docName variable is because
docW.lpszDocName is a LPCWSTR so there were warnings when i had
docW.lpszDocName directly in the call to MultiByteToWideChar.
Changelog
* cleanup w->a cross calls in StartDoc
--
James Hawkins
Index: dlls/gdi/gdi_private.h
===
RCS file: /home/wine/wine/dlls/gdi/gdi_private.h,v
retrieving revision 1.14
diff -u -r1.14 gdi_private.h
--- dlls/gdi/gdi_private.h 6 Aug 2004 18:59:31 - 1.14
+++ dlls/gdi/gdi_private.h 28 Aug 2004 19:55:41 -
@@ -162,7 +162,7 @@
INT (*pSetWindowExt)(PHYSDEV,INT,INT);
INT (*pSetWindowOrg)(PHYSDEV,INT,INT);
BOOL (*pSetWorldTransform)(PHYSDEV,const XFORM*);
-INT (*pStartDoc)(PHYSDEV,const DOCINFOA*);
+INT (*pStartDoc)(PHYSDEV,const DOCINFOW*);
INT (*pStartPage)(PHYSDEV);
BOOL (*pStretchBlt)(PHYSDEV,INT,INT,INT,INT,PHYSDEV,INT,INT,INT,INT,DWORD);
INT (*pStretchDIBits)(PHYSDEV,INT,INT,INT,INT,INT,INT,INT,INT,const void *,
Index: dlls/gdi/printdrv.c
===
RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v
retrieving revision 1.39
diff -u -r1.39 printdrv.c
--- dlls/gdi/printdrv.c 4 May 2004 04:13:06 - 1.39
+++ dlls/gdi/printdrv.c 28 Aug 2004 19:55:41 -
@@ -48,6 +48,7 @@
#include "winreg.h"
#include "wownt32.h"
#include "wine/debug.h"
+#include "wine/unicode.h"
#include "gdi.h"
#include "gdi_private.h"
#include "heap.h"
@@ -61,7 +62,7 @@
/**
- * StartDocA [EMAIL PROTECTED]
+ * StartDocW [EMAIL PROTECTED]
*
* StartDoc calls the STARTDOC Escape with the input data pointing to DocName
* and the output data (which is used as a second input parameter).pointing at
@@ -70,13 +71,14 @@
*
* Note: we now do it the other way, with the STARTDOC Escape calling StartDoc.
*/
-INT WINAPI StartDocA(HDC hdc, const DOCINFOA* doc)
+INT WINAPI StartDocW(HDC hdc, const DOCINFOW* doc)
{
INT ret = 0;
DC *dc = DC_GetDCPtr( hdc );
TRACE("DocName = '%s' Output = '%s' Datatype = '%s'\n",
- doc->lpszDocName, doc->lpszOutput, doc->lpszDatatype);
+ debugstr_w(doc->lpszDocName), debugstr_w(doc->lpszOutput),
+ debugstr_w(doc->lpszDatatype));
if(!dc) return SP_ERROR;
@@ -86,31 +88,41 @@
}
/*
- * StartDocW [EMAIL PROTECTED]
+ * StartDocA [EMAIL PROTECTED]
*
*/
-INT WINAPI StartDocW(HDC hdc, const DOCINFOW* doc)
+INT WINAPI StartDocA(HDC hdc, const DOCINFOA* doc)
{
-DOCINFOA docA;
-INT ret;
-
-docA.cbSize = doc->cbSize;
-docA.lpszDocName = doc->lpszDocName ?
- HEAP_strdupWtoA( GetProcessHeap(), 0, doc->lpszDocName ) : NULL;
-docA.lpszOutput = doc->lpszOutput ?
- HEAP_strdupWtoA( GetProcessHeap(), 0, doc->lpszOutput ) : NULL;
-docA.lpszDatatype = doc->lpszDatatype ?
- HEAP_strdupWtoA( GetProcessHeap(), 0, doc->lpszDatatype ) : NULL;
-docA.fwType = doc->fwType;
-
-ret = StartDocA(hdc, &docA);
-
-if(docA.lpszDocName)
-HeapFree( GetProcessHeap(), 0, (LPSTR)docA.lpszDocName );
-if(docA.lpszOutput)
-HeapFree( GetProcessHeap(), 0, (LPSTR)docA.lpszOutput );
-if(docA.lpszDatatype)
-HeapFree( GetProcessHeap(), 0, (LPSTR)docA.lpszDatatype );
+DOCINFOW docW;
+INT ret, len;
+LPWSTR docName, output, dataType;
+
+docW.cbSize = doc->cbSize;
+
+len = MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, NULL, 0 );
+docName = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) );
+MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, docName, len );
+
+len = MultiByteToWideChar( CP_ACP, 0, doc->lpszOutput, -1, NULL, 0 );
+output = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) );
+MultiByteToWideChar( CP_ACP, 0, doc->lpszOutput, -1, output, len );
+
+len = MultiByteToWideChar( CP_ACP, 0, doc->lpszDatatype, -1, NULL, 0 );
+dataType = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) );
+Mul
Re: Other W->A crosscalls
On Wed, 25 Aug 2004, Rolf Kalbermatter wrote:
[...]
> I see many "xxxAW calls xxxA function" mainly in the shell related DLLs. This
> is of course not something you can really get rid of, so the script should
> be able to exclude those cases.
I couldn't test as I don't have smatch, but I think that simply adding
this line in the right place should do the trick.
$func_in = "No function" if ($func_in =~ /AW$/);
See the attached script.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
We are Pentium of Borg. You will be approximated. Division is futile.#!/usr/bin/perl
use smatch;
my $tmp;
my $func_in;
my $func_called;
while (my $data = get_data()) {
if ($data =~ /^function_decl (.*?)function_decl\((.*?)W\)/) {
$func_in = "$2W";
$func_in = "No function" if ($func_in =~ /AW$/);
} elsif ($data =~ /^function_decl (.*?)function_decl\((.*?)\)/) {
$func_in = "No function";
}
if (not $func_in =~ /^No function$/) {
$tmp = $data;
while ($tmp =~ /call_expr\(\(addr_expr function_decl\(([^\)]*?)\)(.*)/) {
$func_called = $1;
$tmp = $2;
if ($func_called =~ /(.*?)A$/) {
print get_filename(), " ", get_lineno(), " $func_in: call to $func_called\n";
}
}
}
}
Re: wine/ windows/painting.c dlls/user/painting.c
On Wed, 25 Aug 2004 19:46:11 -0500, you wrote:
> Log message:
> GetUpdateRgn should clip the returned region to the client area.
> Changed GetUpdateRect and ExcludeUpdateRgn to call GetUpdateRgn.
> Moved these 3 functions to dlls/user/painting.c.
This has the effect that a program that like agent does this:
case WM_PAINT:
if( GetUpdateRect(hWnd, ...) {
hdc = BeginPaint(hWnd,...);
}
causes a lot of:
err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd
0x1002c!
Is it not possible to restrict the update region to the client area in
the first place?
Rein.
--
Rein Klazes
[EMAIL PROTECTED]
Re: W->A cleanup of DirectDrawEnumerateEx part 1
On Sat, 28 Aug 2004 13:30:40 -0400, James Hawkins wrote: > I guess this is one of the w->a cases that shouldnt be fixed if this > is the case. Pretty much anything which involves changing public structures (ie declared in the headers in include/) is probably wrong, as not all the Windows APIs are unicode. You can always check to see if the definition is on MSDN if you aren't sure when something is public or not. thanks -mike
Debug Channels trashed
Hallo, I am trying to run the WebPACK_42wp30_full_installer.exe : http://direct.xilinx.com/direct/webpack/42wp3/\ : WebPACK_42wp30_full_installer.exe (a 110 MByte Download). Running it crashes quite early, while testing the debug channels: err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TrueType" err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TT" wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405ac2f0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xc0685566 in 32-bit code (0x40710c60). In 32 bit mode. 0x40710c60 WINPROC_CallWndProc [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) 232 if (TRACE_ON(relay)) 232 if (TRACE_ON(relay)) Wine-dbg>Backtrace: =>1 0x40710c60 WINPROC_CallWndProc+0x70(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32 (0x4067fb7c) 2 0x4071578d CallWindowProcA+0xed(func=0x4078656c, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fba0) 3 0x406eb083 DefDlgProcA+0x63(hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/defdlg.c:451] in user32 (0x4067fbd0) 4 0x40710437 WINPROC_wrapper+0x17 in user32 (0x4067fbf4) 5 0x40710c4c WINPROC_CallWndProc+0x5c(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:230] in user32 (0x4067fc30) 6 0x4071578d CallWindowProcA+0xed(func=0x406eb020, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fc54) 7 0x40725b8f call_window_proc+0x11f(lparam=0x0, unicode=0x0, same_thread=0x1) [/home/wine/wine/dlls/user/message.c:1461] in user32 (0x4067fcb8) 8 0x4072839e SendMessageTimeoutA+0x1be(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0, flags=0x0, timeout=0x, res_ptr=0x4067fd3c) [/home/wine/wine/dlls/user/message.c:1968] in user32 (0x4067fd18) 9 0x40728425 SendMessageA+0x35(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0) [/home/wine/wine/dlls/user/message.c:2012] in user32 (0x4067fd44) 10 0x406efc5c DIALOG_CreateIndirect+0x107c(dlgProc=0x4012df, param=0x0, unicode=0x0, modal=0x1) [/home/wine/wine/dlls/user/../../windows/dialog.c:672] in user32 (0x4067fe54) 11 0x406f04be DialogBoxParamA+0x4e(hInst=0x40, name=0x12c, owner=0x0, dlgProc=0x4012df, param=0x0) [/home/wine/wine/dlls/user/../../windows/dialog.c:821] in user32 (0x4067fe78) 12 0x0040184d (0x004137a2) It seems the location of the debug channels is picked up from the ebx register Wine-dbg>disass 0x40710c52 0x40710c52 WINPROC_CallWndProc [../windows/winproc.c:231] in user32: call 0x40707c70 WIN_RestoreWndsLock [/home/wine/wine/dlls/user/../../windows/user.c:183] in user32 0x40710c57 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: movl 0x190(%ebx),%eax 0x40710c5d WINPROC_CallWndProc [../windows/winproc.c:232] in user32: addl $24,%esp 0x40710c60 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) I wonder what can trash the testing of the debug channels. I ran with +heap to look for heap corruption, but couldn't find something. Uncommenting the offending code > if (TRACE_ON(relay)) >DPRINTF( "%04lx:Ret window proc %p (hwnd=%p,msg=%s,wp=%08x,lp=%08lx) > retval=%08lx\n", > GetCurrentThreadId(), proc, hwnd, SPY_GetMsgName(msg, hwnd), wParam, lParam, > retvalue ); makes the application proceed. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: W->A cleanup of DirectDrawEnumerateEx part 1
I guess this is one of the w->a cases that shouldnt be fixed if this is the case. On Sat, 28 Aug 2004 18:30:50 +0200, Lionel Ulmer <[EMAIL PROTECTED]> wrote: > On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote: > > Changelog > > * change szDriver and szDescription from char to WCHAR in > > DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2. > > Well, this seems completely wrong to me. Why Unicodify an API that has no > Unicode equivalent in Microsoft code ? > > If I look at the platform SDK, this structure is defined with a 'char', so I > wonder why you would choose to deviate from the standard ? > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ > > -- James Hawkins
Re: W->A cleanup of DirectDrawEnumerateEx part 4
On Sat, Aug 28, 2004 at 12:20:24PM -0400, James Hawkins wrote: > Changelog > * cleanup cross calls in DirectDrawEnumerateEx To continue with my other mail, you should have sent all this in one big patch as (from what I can see) it cannot work if you do not apply all 4 parts in one go. Anyway, the 'problem' in Wine is that it uses the DDDEVICEIDENTIFIER2 structure to hold driver information. But, as this information is also exported via API calls like the 'GetDeviceIdentifier' method from the DDraw COM object, you cannot just Unicodify it, you need to let it in ASCII (as there are no, AFAIK, Unicode versions of any of the DirectX < 8 APIs). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: W->A cleanup of DirectDrawEnumerateEx part 1
On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote: > Changelog > * change szDriver and szDescription from char to WCHAR in > DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2. Well, this seems completely wrong to me. Why Unicodify an API that has no Unicode equivalent in Microsoft code ? If I look at the platform SDK, this structure is defined with a 'char', so I wonder why you would choose to deviate from the standard ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: W->A cleanup of DirectDrawEnumerateEx part 4
You should post one patch not four that depend upon each other. Rule of Thumb: * After each patch is applied, the CVS should build and work. Mike James Hawkins wrote: Changelog * cleanup cross calls in DirectDrawEnumerateEx
Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
Mike Hearn wrote: Well, apparently we don't use sched_yield, so the problem must lie somewhere else. Maybe Con can help us out here? Alexandre says he doesn't know what the issue is either and somebody needs to investigate. I guess we do need to concern ourselves over the details :) Interesting. Probably the most valuable information is that it seems to work fine if we artificially limit the threads to exactly the same timeslice _or_ we put them at such a low priority that they are forced to be guaranteed to round robin one task at a time. This is the way 2.4 used to work which is why with the new 2.6 schedulers which do far more out-of-order rescheduling some applications have a problem; particularly under load. I suspect it's actually the latter issue. Locking between threads should prevent that being a problem, though. You already mentioned that you dont use sched_yield() and I couldn't even begin to look at the wine code myself so perhaps you know something more. Hi Con, One thought that occurred to me, and this is just a random theory, is that maybe the issue is not with the Wine code but the Win32 code run on top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows (NT) scheduling? Could it be that some apps are written to expect Windows-style scheduling and fail to work if they don't get it? I argued with myself about the logic in this for ages. The best I could come up with is - I don't know :| I'd need to know about windows scheduling (which I don't) and how wine treats that scheduling (which I also don't). Cheers, Con signature.asc Description: OpenPGP digital signature
RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars
Is there anything wrong with this patch? I can't see my changes taken place in CVS. Let me know and I'll fix 'em. /J -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jens Collin Sent: den 8 augusti 2004 17:55 To: [EMAIL PROTECTED] Subject: patch: shell32.dll - SHELL_ArgifyW expands env-vars changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).
Re: working together on stdole.tlb and a end to dcom9x
It basically involves implementing the ICreateTypeLib interfaces in our OLE dlls. Nyef did some great work on this but for stdole32.tlb we need the other version, I think. Once this is done maybe we can pull the stdole32.tlb generation program used in Crossover upstream. Right now it's pretty useless for Wine as it has to be run on Windows to work. On Fri, 27 Aug 2004 23:26:07 -0700, Steven Edwards wrote: > Hello, > Once again cross-posting because I would like to see if this is > something we can work together on. What is left to do for us to be able > to build and have a working implementation of stdole.tlb or any other > type libs? I ask because it seems Wines DCOM implementaton is almost > good enough for most apps except for this file and ReactOS is quickly > getting to the point that it can run most of the same stuff Wine can > without DCOM9x installed. > > Thanks > Steven > > > > > ___ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush
Richedit control
Hi All,
I'm going to play with the richedit control to try get it to draw RTF
documents with formatting. My plan is to write a program that can
display but not edit, then let somebody else add the editting
functionality afterwards :) Once I can get the attached program to
work, the plan is to change the code in text-writer.c to add the
formatting information to the richedit control via standard richedit
messages. If anybody is already working on it, or wants to have a go,
let me know.
Mike
#include
#include
#include
#include
void fill_richedit( HWND hwnd )
{
PARAFORMAT pf;
CHARFORMAT cf;
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "this is a test\n");
// add text on the right
memset( &pf, 0, sizeof pf );
pf.cbSize = sizeof pf;
pf.dwMask = PFM_ALIGNMENT;
pf.wAlignment = PFA_RIGHT;
SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "right\n");
// add text in the center
memset( &pf, 0, sizeof pf );
pf.cbSize = sizeof pf;
pf.dwMask = PFM_ALIGNMENT;
pf.wAlignment = PFA_CENTER;
SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "centre\n");
// add text on the left
memset( &pf, 0, sizeof pf );
pf.cbSize = sizeof pf;
pf.dwMask = PFM_ALIGNMENT;
pf.wAlignment = PFA_LEFT;
SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "left\n");
// add bold text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_BOLD;
cf.dwEffects = CFE_BOLD;
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "bold ");
// add italic text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_ITALIC | CFM_BOLD;
cf.dwEffects = CFE_ITALIC;
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "italic ");
// add underlined text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE;
cf.dwEffects = CFE_UNDERLINE;
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "underline ");
// add strikeout text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE | CFM_STRIKEOUT;
cf.dwEffects = CFE_STRIKEOUT;
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "strikeout");
// add normal text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_BOLD | CFM_ITALIC | CFM_UNDERLINE | CFM_STRIKEOUT;
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) " normal\n");
// add red text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_COLOR;
cf.crTextColor = RGB(255,0,0);
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "red ");
// add green text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_COLOR;
cf.crTextColor = RGB(0,255,0);
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "green ");
// add blue text
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_COLOR;
cf.crTextColor = RGB(0,0,255);
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "blue\n");
// try some fonts
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_FACE | CFM_SIZE;
cf.yHeight = 300;
strcpy(cf.szFaceName, "Tahoma");
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "tahoma ");
// try some fonts
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_FACE;
strcpy(cf.szFaceName, "Helvetica");
SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf);
SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "Helvetica ");
// try some fonts
memset( &cf, 0, sizeof cf );
cf.cbSize = sizeof cf;
cf.dwMask = CFM_FACE;
