winetest, winrash and new volunteers
Hi, as can be seen from the test.winehq.org site the number of test-runs dramatically dropped. Apart from the fact that there were problems with the automated download of new tests by winrash: http://www.winehq.org/hypermail/wine-devel/2005/03/0373.html winetest will not run but bail out because there is no visible desktop. 3 of the 5 (!) tests that are now there, where done by me. Where in a 'normal' case we should already have dozens. I don't want to go into a discussion about the fact that 'running as a service' and 'on a visible desktop' can/cannot live together properly. Or why we should have 'visible' tests or not. I just want to have as much tests run as possible. I mean that was the whole idea behind it right? An approach should be decided upon: - Have (again) volunteers who run the winetest manually/interactively - Use winrash and have every test decide whether it needs interactivity - 'Fix' winrash so tests run, maybe semi-automated, on a visible desktop - An approach for the last is to have winrash fill in one of the 'run' keys (as it does on win98 already during install). I will be/stay a volunteer for the first approach until we decide what to do. Cheers, Paul.
Steam again (Re: Black Text)
On Fri, 2005-03-11 at 18:31 -0700, Ian Bartelds! wrote: Ok here's where I am at.. I get these errors when I just do wine program.exe err:wave:wodDsCreate DirectSound flag not set This sound card's driver does not support direct access The (slower) DirectSound HEL mode will be used instead. fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403e7db8)-(00010024,0053) fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:ddraw:Main_DirectDrawClipper_Initialize (0x403e86b0)-(0x403e7dc4,0x),stub! fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now. fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank (0x403e7db8)-(flags=0x0001,handle=(nil)) fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum Now when I go WINEDEBUG=+relay wine legend.exe I get this huge list which basicly has : 0009:Call ntdll.RtlLeaveCriticalSection(40360db0) ret=404f714f 0009:Ret ntdll.RtlLeaveCriticalSection() retval= ret=404f714f 0009:Call ntdll.RtlFreeHeap(4036,,40360db0) ret=404cd2fd 0009:Call ntdll.RtlDeleteCriticalSection(40360db0) ret=404f71ad Now I don't really see anything to do with text. Thanks Ian Bartelds On March 11, 2005 05:26 pm, Ian Bartelds! wrote: I am compiling the cvs tree with --enable-debug so I will try it like this.. Peace Ian Bartelds On March 11, 2005 05:09 pm, Jonathan Ernst wrote: Le vendredi 11 mars 2005 à 16:08 -0700, Ian Bartelds! a écrit : Hey it's me again I try and do a WINEDEBUG=+all and it does nothing, I am using the gentoo linux version that I downloaded and compiled through portage Thanks Ian Bartelds recompile wine using debug USE flag: ACCEPT_KEYWORDS=~x86 USE=debug emerge wine http://tuzakey.com/~scott/steam.png Is this the same problem in Steam? I can't figure out how to make the text readable in the latest release. This is with a standard Wine + Winetools base setup install, and added Managed=N to the config (since otherwise Steam breaks.) Help would be much appreciated by us all :) Thanks, Scott Ritchie
Noteworthy Composer under WineDbg
I have been unable to find the reason Wine MIDI Mapper does not open
properly. The trace below shows the output from winedbg with WINDEBUG
set to +all. I hope someone can tell me what is going on.
Andrew
[EMAIL PROTECTED] Default]$ set WINEDEBUG=+all
[EMAIL PROTECTED] Default]$ winedbg ~/.wine/drive_c/Program
Files/NoteWorthy Composer/NWC32.EXE
WineDbg starting on pid 0xa
In 32 bit mode.
0x404d7dbf start_process+0xcf
[/home/andrew/Download/Software/wine-20050211/dlls/kernel/../../include/winternl.h:1356]
in kernel32: jmp0x404d7db5 start_process+0xc5
[/home/andrew/Download/Software/wine-20050211/dlls/kernel/process.c:1046]
in kernel32
1356static inline void WINAPI DbgBreakPoint(void) { __asm__
__volatile__(int3); }
Wine-dbgnext
1046ExitProcess( entry( peb ) );
Wine-dbgnext
err:thunk:_loadthunk (NWMID95B.DLT, thunkobj_ThunkData16, NWMID95B.DLL):
Unable to load 'NWMID95B.DLT', error 2
fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer
EPSONStylusC42?!
fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum
fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum
Invalid address (0x404d7db8) for breakpoint 0, disabling it
Process of pid=0x000a has terminated
Wine-dbgquit
WineDbg terminated on pid 0xa
[EMAIL PROTECTED] Default]$
--
Andrew
[hackcoughsniffle]
Internal Virus Database corrupt
Re: wine 20050310
James, I thought these issues were caused by Patch: http://cvs.winehq.org/patch.py?id=14725 James Hawkins wrote: On Fri, 11 Mar 2005 15:49:08 -0700, Kevin DeKorte [EMAIL PROTECTED] wrote: The latest wine still has issues with Notes 6.51 that started in the 20050111 release. Basically if you open Notes and click on one of the bookmarks on the bookmark bar on the left, wine will consume all the CPU. Killing wineserver and wine-preload returns the machine to normal. Wine 20041201 works fine. Kevin Can you do a regression test of this problem to find out the exact patch that causes the change? If we know the exact patch, it will be much easier to find a solution. See: http://winehq.org/site/docs/wine-devel/x1318
Response from NoteWorthy
I wrote NoteWorthy support about the problem of opening the MIDI mapper. Here is their response. Hi: My question is how do you detect the MIDI mappers ? The MIDI Mapper actually has a hard coded device ID on Windows. There is no need to detect it. Any other device listed in Tools, Options, Midi, Available play devices are detected using the multi-media subsystem. Regards, Eric, http://noteworthysoftware.com -- Andrew [hackcoughsniffle] Internal Virus Database corrupt
Re: Noteworthy Composer under WineDbg
err:thunk:_loadthunk (NWMID95B.DLT, thunkobj_ThunkData16, NWMID95B.DLL): Unable to load 'NWMID95B.DLT', error 2 wine dies because of this... it cannot find (or load) nwmid95b.dlt A+ -- Eric Pouech
Re: wine 20050310
On Sat, 12 Mar 2005 14:19:51 +0100, Grant Williamson wrote: James, I thought these issues were caused by Patch: http://cvs.winehq.org/patch.py?id=14725 Yes, it's a WM rewrite regression.
Re: Theming for Wine via the registry
On Fri, 11 Mar 2005 00:16:16 -0800, Scott Ritchie wrote: This thread on the forums caught my attention: http://www.ubuntuforums.org/showthread.php?p=86939highlight=wine#post86939 1) Is there a way we can make Wine respect the current GTK themes? Wasn't someone working on this a while ago? What's the status? Yeah, but it's an awful lot of work. It basically means rewriting the Wine widget drawing code to support themes, and then writing a uxtheme-gtk bridge layer. Bridging just the colours is inadvisable. It works OK for the new Clearlooks/Human theme but for some themes (eg Industrial) it looks horrible. That said we should definitely alter the Wine colour scheme, in fact it came up internally in CodeWeavers a few days ago. 2) If I want to hack around this by changing the default registry for the Ubuntu packages, what's the best way to do that? Just have a custom .reg file and run it through regedit in the postinst script. thanks -mike
Re: wine/ misc/registry.c documentation/samples/config
Hi Alexandre, What is the thinking behind this patch? If we don't load the Windows registry on startup where should it be loaded? Will this code re-appear at any point in the future? A significant number of users still expect to be able to point Wine at an actual Windows install despite what we recommend. thanks -mike On Fri, 11 Mar 2005 07:10:25 -0600, Alexandre Julliard wrote: ChangeSet ID: 16565 CVSROOT: /opt/cvs-commit Module name: wine Changes by: [EMAIL PROTECTED] 2005/03/11 07:10:25 Modified files: misc : registry.c documentation/samples: config Log message: Get rid of the Windows registry loading on startup, this needs to be done differently. Patch: http://cvs.winehq.org/patch.py?id=16565 Old revision New revision Changes Path 1.149 1.150 +6 -1498wine/misc/registry.c 1.73 1.74 +0 -2 wine/documentation/samples/config
Re: [DSOUND] little patch
Raphael wrote:
- This-lock.DebugInfo-Spare[1] = 0;
+ /*This-lock.DebugInfo-Spare[1] = 0;*/
DeleteCriticalSection((This-lock));
You have to zero this out or DeleteCriticalSection will try
to delete that static memory.
How ?
At opposite it produce DebugInfo leaks
as seen in RtlDeleteCriticalSection (dlls/ntdll/critsection.c line 197)
snip
if (crit-DebugInfo)
{
/* only free the ones we made in here */
if (!crit-DebugInfo-Spare[1])
{
RtlFreeHeap( GetProcessHeap(), 0, crit-DebugInfo );
crit-DebugInfo = NULL;
}
}
Actually it will leak DebugInfo if DebugInfo-Spare[1] is not 0.
snip
i will provide a WINE_DEBUG_UNSET_CS_NAME for this problem
...
+#define WINE_SET_CS_NAME(cs, name) (cs)-DebugInfo-Spare[1] = (DWORD)
name +#define WINE_GET_CS_NAME(cs) (const char*)
(cs)-lock.DebugInfo-Spare[1]
This is a wine specific trick and should probably be put somewhere global
so all users can be consistent. The name should have DEBUG in it
somewhere.
Yes, it should be better
but i prefered to centralize it on dsound before moving it to wine/debug.h
Regards,
Raphael
This is Alexandre's trick which I borrowed because it is very helpful in
debugging lock problems.
It would be nice to formalize this and make it available in a more
general way but that is Alexandre's call.
Re: wine/ misc/registry.c documentation/samples/config
On Sat, 12 Mar 2005 16:20:42 +0100, Alexandre Julliard wrote: There should be an import existing Windows drive function in winecfg, or something along those lines, that would create symlinks to the Windows install and import the registry. You mean by moving the native registry loading code out of the Wine core? Is anybody working on this, or will it just be a feature regression until somebody changes the way we use native drives?
Re: [DSOUND] little patch
+#define WINE_SET_CS_NAME(cs, name) (cs)-DebugInfo-Spare[1] =
(DWORD)
name +#define WINE_GET_CS_NAME(cs) (const char*)
(cs)-lock.DebugInfo-Spare[1]
This is a wine specific trick and should probably be put somewhere
global
so all users can be consistent. The name should have DEBUG in it
somewhere.
Yes, it should be better
but i prefered to centralize it on dsound before moving it to
wine/debug.h
Regards,
Raphael
This is Alexandre's trick which I borrowed because it is very helpful
in debugging lock problems.
It would be nice to formalize this and make it available in a more
general way but that is Alexandre's call.
Something like this plus a lot of documentation explaining what is going on.
I think this should go in debug.h but there is only trace stuff in there
so I put it in library.h.
Compile tested only.
Index: dlls/dsound/buffer.c
===
RCS file: /home/wine/wine/dlls/dsound/buffer.c,v
retrieving revision 1.47
diff -u -p -r1.47 buffer.c
--- dlls/dsound/buffer.c16 Feb 2005 16:09:03 - 1.47
+++ dlls/dsound/buffer.c12 Mar 2005 15:20:33 -
@@ -32,6 +32,7 @@
#include dsound.h
#include dsdriver.h
#include dsound_private.h
+#include wine/library.h
WINE_DEFAULT_DEBUG_CHANNEL(dsound);
@@ -365,7 +366,7 @@ static ULONG WINAPI IDirectSoundBufferIm
if (!ref) {
DSOUND_RemoveBuffer(This-dsound, This);
- This-lock.DebugInfo-Spare[1] = 0;
+wine_dbg_remove_lock_name((This-lock));
DeleteCriticalSection((This-lock));
if (This-hwbuf) {
@@ -1176,7 +1177,7 @@ HRESULT WINAPI IDirectSoundBufferImpl_Cr
DSOUND_RecalcVolPan((dsb-volpan));
InitializeCriticalSection((dsb-lock));
-dsb-lock.DebugInfo-Spare[1] = (DWORD)DSOUNDBUFFER_lock;
+wine_dbg_add_lock_name((dsb-lock), DSOUNDBUFFER_lock);
/* register buffer if not primary */
if (!(dsbd-dwFlags DSBCAPS_PRIMARYBUFFER)) {
@@ -1184,7 +1185,7 @@ HRESULT WINAPI IDirectSoundBufferImpl_Cr
if (err != DS_OK) {
HeapFree(GetProcessHeap(),0,dsb-buffer-memory);
HeapFree(GetProcessHeap(),0,dsb-buffer);
- dsb-lock.DebugInfo-Spare[1] = 0;
+wine_dbg_remove_lock_name((dsb-lock));
DeleteCriticalSection((dsb-lock));
HeapFree(GetProcessHeap(),0,dsb-pwfx);
HeapFree(GetProcessHeap(),0,dsb);
Index: dlls/dsound/dsound.c
===
RCS file: /home/wine/wine/dlls/dsound/dsound.c,v
retrieving revision 1.30
diff -u -p -r1.30 dsound.c
--- dlls/dsound/dsound.c25 Feb 2005 16:50:57 - 1.30
+++ dlls/dsound/dsound.c12 Mar 2005 15:20:34 -
@@ -35,6 +35,7 @@
#include dsound.h
#include dsdriver.h
#include dsound_private.h
+#include wine/library.h
WINE_DEFAULT_DEBUG_CHANNEL(dsound);
@@ -285,7 +286,7 @@ static ULONG WINAPI IDirectSoundImpl_Rel
HeapFree(GetProcessHeap(),0,This-tmp_buffer);
HeapFree(GetProcessHeap(),0,This-buffer);
RtlDeleteResource(This-buffer_list_lock);
-This-mixlock.DebugInfo-Spare[1] = 0;
+wine_dbg_remove_lock_name(This-mixlock);
DeleteCriticalSection(This-mixlock);
HeapFree(GetProcessHeap(),0,This);
dsound = NULL;
@@ -581,13 +582,13 @@ static HRESULT WINAPI IDirectSoundImpl_D
CopyMemory(dsb-pwfx, pdsb-pwfx, size);
InitializeCriticalSection((dsb-lock));
-dsb-lock.DebugInfo-Spare[1] = (DWORD)DSOUNDBUFFER_lock;
+wine_dbg_add_lock_name((dsb-lock), DSOUNDBUFFER_lock);
/* register buffer */
hres = DSOUND_AddBuffer(This, dsb);
if (hres != DS_OK) {
IDirectSoundBuffer8_Release(psb);
-dsb-lock.DebugInfo-Spare[1] = 0;
+wine_dbg_remove_lock_name((dsb-lock));
DeleteCriticalSection((dsb-lock));
HeapFree(GetProcessHeap(),0,dsb-buffer);
HeapFree(GetProcessHeap(),0,dsb-pwfx);
@@ -943,7 +944,7 @@ HRESULT WINAPI IDirectSoundImpl_Create(
}
InitializeCriticalSection((pDS-mixlock));
-pDS-mixlock.DebugInfo-Spare[1] = (DWORD)DSOUND_mixlock;
+wine_dbg_add_lock_name((pDS-mixlock), DSOUND_mixlock);
RtlInitializeResource((pDS-buffer_list_lock));
Index: include/wine/library.h
===
RCS file: /home/wine/wine/include/wine/library.h,v
retrieving revision 1.35
diff -u -p -r1.35 library.h
--- include/wine/library.h 11 Jan 2005 10:46:58 - 1.35
+++ include/wine/library.h 12 Mar 2005 15:20:39 -
@@ -67,6 +67,19 @@ extern int (*__wine_dbg_vlog)( unsigned
extern void wine_dbg_add_option( const char *name, unsigned char set, unsigned
char clear );
extern int wine_dbg_parse_options( const char *str );
+inline static void wine_dbg_add_lock_name( CRITICAL_SECTION *cs, const char
Re: Noteworthy Composer under WineDbg
Further detail interspersed
Andrew
[hackcoughsniffle]
Internal Virus Database corrupt
Andrew Neil Ramage wrote:
I have been unable to find the reason Wine MIDI Mapper does not open
properly. The trace below shows the output from winedbg with WINDEBUG
set to +all. I hope someone can tell me what is going on.
Andrew
[EMAIL PROTECTED] Default]$ set WINEDEBUG=+all
[EMAIL PROTECTED] Default]$ winedbg ~/.wine/drive_c/Program
Files/NoteWorthy Composer/NWC32.EXE
WineDbg starting on pid 0xa
In 32 bit mode.
0x404d7dbf start_process+0xcf
[/home/andrew/Download/Software/wine-20050211/dlls/kernel/../../include/winternl.h:1356]
in kernel32: jmp0x404d7db5 start_process+0xc5
[/home/andrew/Download/Software/wine-20050211/dlls/kernel/process.c:1046]
in kernel32
1356static inline void WINAPI DbgBreakPoint(void) { __asm__
__volatile__(int3); }
Wine-dbgnext
1046ExitProcess( entry( peb ) );
Wine-dbgnext
Normal start of program - main window opens and tips dialog displayed
err:thunk:_loadthunk (NWMID95B.DLT, thunkobj_ThunkData16, NWMID95B.DLL):
Unable to load 'NWMID95B.DLT', error 2
fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer
EPSONStylusC42?!
No such dialog is displayed
Load song file and press Play. NWC reports that the MIDI device is
not set up and asks if you want to open the dialog.to fix the problem.
WineMIDI Mapper is selected, as the default midi mapper, but pressing OK
results in the same error message from Noteworthy. Either pressing
Cancel or removing the Wine MIDI Mapper allows the dialog to close.
fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum
The notes on the display are highlighted as normal but no sound is
generated.
Quit application
fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum
Invalid address (0x404d7db8) for breakpoint 0, disabling it
Process of pid=0x000a has terminated
Wine-dbgquit
WineDbg terminated on pid 0xa
[EMAIL PROTECTED] Default]$
Re: wine/ misc/registry.c documentation/samples/config
Mike Hearn [EMAIL PROTECTED] writes: Is anybody working on this, or will it just be a feature regression until somebody changes the way we use native drives? Nobody's working on it, so it won't be supported until someone cares enough to do it. I encouraged a few people to start working on it but nobody did, so taking out the existing support is a way to provide more encouragement. If that's not enough then the feature simply won't be supported anymore. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Theming for Wine via the registry
On Saturday 12 March 2005 14:08, Mike Hearn wrote: On Fri, 11 Mar 2005 00:16:16 -0800, Scott Ritchie wrote: This thread on the forums caught my attention: http://www.ubuntuforums.org/showthread.php?p=86939highlight=wine#post86939 1) Is there a way we can make Wine respect the current GTK themes? Wasn't someone working on this a while ago? What's the status? Yeah, but it's an awful lot of work. It basically means rewriting the Wine widget drawing code to support themes, and then writing a uxtheme-gtk bridge layer. I may look at this in the future, it's important for wine to integrate with any accessibility tools provided by either QT or GTK if wine is to reach UK accessibility requirements, using GTK and QT widgets seems the best way to do this. has anyone looked at doing this in the past? Bridging just the colours is inadvisable. It works OK for the new Clearlooks/Human theme but for some themes (eg Industrial) it looks horrible. That said we should definitely alter the Wine colour scheme, in fact it came up internally in CodeWeavers a few days ago. Some of the colours can be transferred like window background, to get part of the way there. pgp3AawuKgmbh.pgp Description: PGP signature
Re: Theming for Wine via the registry
On Sat, 12 Mar 2005 17:25:58 +, Oliver Stieber wrote: I may look at this in the future, it's important for wine to integrate with any accessibility tools provided by either QT or GTK if wine is to reach UK accessibility requirements, using GTK and QT widgets seems the best way to do this. has anyone looked at doing this in the past? Ah, that's different. That'd actually require using Gtk/Qt which we cannot do, the best we can get is to look like them. To be fully accessible we'd need to implement the OLE Accessibility framework and bridge it to AT-SPI or something similar. Some of the colours can be transferred like window background, to get part of the way there. You'd think so, but I've seen a screenshot of Wine Industrialised and it was truly terrible, unusable even. You really need to use the proper widget drawing code to make it look good IMHO if the colours are very different to what Windows normally uses. A good start would just be to import the Win2K colour scheme. thanks -mike
Re: Wine release 20050310 (2/2) and (1/2)
Hi Julliard, Your last two emails, Wine release 20050310 (1/2) and Wine release 20050310 (2/2), were received with no text and only an attachment with no file extension. Regards, Brian Alexandre Julliard wrote: -- OpenOffice Suite 1.1.4 : Firefox Browser 1.0.1 : Thunderbird Email 1.0
Re: [OLE #82] Implement VT_BYREF | VT_BSTR marshalling
Mike Hearn wrote: Implement VT_BYREF | VT_BSTR marshalling Hi Mike, I've got a bigger patch in my tree at the moment that has your patch plus VT_BYREF|VT_BSTR unmarshaling, plus some other types. The thing now blocking InstallShield seems to be a nasty deadlock in the COM code that I haven't figured out yet. Rob
Re: [OLE #82] Implement VT_BYREF | VT_BSTR marshalling
On Sat, 2005-03-12 at 11:45 -0600, Rob Shearman wrote:
I've got a bigger patch in my tree at the moment that has your patch
plus VT_BYREF|VT_BSTR unmarshaling, plus some other types. The thing now
blocking InstallShield seems to be a nasty deadlock in the COM code that
I haven't figured out yet.
Ah OK cool, ignore that one then Alexandre, I'll let Rob submit it.
Also FWIW I am seeing a DCOM crash here for InstallShield:
Unhandled exception: page fault on read access to 0x0008 in 32-bit code
(0x0095db72).
In 32 bit mode.
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:0095db72 ESP:0e889aa0 EBP:0e889aac EFLAGS:00010246( - 00 -RIZP1)
EAX: EBX:0096a248 ECX:005fe718 EDX:0096e900
ESI:005fe718 EDI:
Stack dump:
0x0e889aa0: 0096a248 0008 0096e900 0e889af8
0x0e889ab0: 0095de76 005fe718 bfd6f730 009f7770
0x0e889ac0: 0e889ad8 0e889ae0 00a0168a 77de001c
0x0e889ad0: 0018 0008 03020005
0x0e889ae0: 0018 0001 0096a248
0x0e889af0: 005fe718 005fe718 0e889b24 0095e35b
Backtrace:
=1 0x0095db72 I_RpcGetBuffer+0x22(pMsg=0x5fe718)
[/wine/dlls/rpcrt4/rpc_message.c:453] in rpcrt4 (0x0e889aac)
2 0x0095de76 RPCRT4_Receive(Connection=0xbfd6dde8, Header=0xe889b10,
pMsg=0x5fe718) [/wine/dlls/rpcrt4/rpc_message.c:373] in rpcrt4 (0x0e889af8)
3 0x0095e35b I_RpcReceive(pMsg=0x5fe718)
[/wine/dlls/rpcrt4/rpc_message.c:572] in rpcrt4 (0x0e889b24)
4 0x0095e4aa I_RpcSendReceive(pMsg=0x5fe718)
[/wine/dlls/rpcrt4/rpc_message.c:619] in rpcrt4 (0x0e889b38)
5 0x009046e7 rpc_sendreceive_thread(param=0xbfd6db70)
[/wine/dlls/ole32/rpc.c:204] in ole32 (0x0e889b50)
6 0x0028c74e in kernel32 (+0x5c74e) (0x0e889c1c)
7 0x00a1a407 start_thread+0x14b(info=0xbfd6dde8)
[/wine/dlls/ntdll/thread.c:201] in ntdll (0x0e88a458)
8 0x00d923ae start_thread+0x7e in libpthread.so.0 (0x0e88a4cc)
9 0x00c11b6e (0x)
0x0095db72 I_RpcGetBuffer+0x22 [/wine/dlls/rpcrt4/rpc_message.c:453] in rpcrt4:
movl0x8(%edi),%edi
453 if (bind-server) {
Re: wine/ misc/registry.c documentation/samples/config
On 12 Mar 2005 17:04:38 +0100, Alexandre Julliard [EMAIL PROTECTED] wrote: Mike Hearn [EMAIL PROTECTED] writes: Is anybody working on this, or will it just be a feature regression until somebody changes the way we use native drives? Nobody's working on it, so it won't be supported until someone cares enough to do it. I encouraged a few people to start working on it but nobody did, so taking out the existing support is a way to provide more encouragement. If that's not enough then the feature simply won't be supported anymore. I'm not sure if this is directly related, but my implementation of RegLoadKeyA/W, NtLoadKey and the server counterpart is almost complete. I'll be gone for a week for spring break, but I will finish it up the following week. -- James Hawkins
Re: wine/ misc/registry.c documentation/samples/config
Hi, --- Mike McCormack [EMAIL PROTECTED] wrote: People would moan and complain, but in the end Wine and Wine users would be better off, as they would no longer depend on anything but Wine to run their Windows software. I have to agree. Short term being able to load the Windows registry and Windows system dlls helped Wine but long term it has led to stagnation. Most of the recent growth in Wine in past few years has been because we are being forced to not be dependant on a existing Windows install or Windows componates such as DCOM IE, MSI, etc which is a good thing. Thanks Steven __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
Re: wine/ misc/registry.c documentation/samples/config
On Sat, 12 Mar 2005 10:35:36 -0800, Steven Edwards wrote: I have to agree. Short term being able to load the Windows registry and Windows system dlls helped Wine but long term it has led to stagnation. Most of the recent growth in Wine in past few years has been because we are being forced to not be dependant on a existing Windows install or Windows componates such as DCOM IE, MSI, etc which is a good thing. I'd have to disagree. I am not really convinced this sort of encouragement works: - We have no config file, yet this has apparently not accelerated the pace of winecfg development, we just have more confused users - Systray patch is being kept out of CVS until it's perfect, but nobody except me has hacked on it for years. There are other examples. Citing stuff like DCOM is misleading, that isn't the sort of thing somebody does to scratch an itch. It's been (and still is) a huge project. It's also somewhat orthogonal to being able to use a real Windows drive. thanks -mike
Re: wine/ misc/registry.c documentation/samples/config
On Sat, Mar 12, 2005 at 06:51:04PM +, Mike Hearn wrote: - We have no config file, yet this has apparently not accelerated the pace of winecfg development, we just have more confused users AFAIK, winecfg is not working with the real registry stuff, so how would not having a config file accelerate it's development? Let's turn winecfg on, then pass judgement on it. -- Dimi.
Re: Theming for Wine via the registry
Ah, that's different. That'd actually require using Gtk/Qt which we cannot do, the best we can get is to look like them. What's the problem, licensing, integration or thread-safety (I know QT isn't thread safe) To be fully accessible we'd need to implement the OLE Accessibility framework and bridge it to AT-SPI or something similar. I may have a look at that too, it would be useful if QT/GTK could use some of the existing Windows accessibility software. I was thinking about going on a fund finding mission, or at least trying to find someone who wants to pay for an initial integration, it shouldn't be too hard as most companies are no where near their requirements. Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: wine/ misc/registry.c documentation/samples/config
On Sat, 2005-03-12 at 21:57 +0100, Alexandre Julliard wrote: And in order to do this we need to get rid of the current registry hacks, the first of which is the Windows registry loading code. Ah OK, I didn't realise this was necessary for winecfg to be activated. thanks -mike
Re: Theming for Wine via the registry
On Sat, 2005-03-12 at 21:00 +, Oliver Stieber wrote: Ah, that's different. That'd actually require using Gtk/Qt which we cannot do, the best we can get is to look like them. What's the problem, licensing, integration or thread-safety (I know QT isn't thread safe) Well all those *could* be problems, but the real problem is that the Windows widget toolkit and GTK/Qt are too different, you can't map between them. I may have a look at that too, it would be useful if QT/GTK could use some of the existing Windows accessibility software. No, that's not what I meant. Implementing OLE accessibility would mean that Win32 apps on Wine appear to in native tools like at-poke. It wouldn't mean you could use win32 accessibility software to access native apps. I was thinking about going on a fund finding mission, or at least trying to find someone who wants to pay for an initial integration, it shouldn't be too hard as most companies are no where near their requirements. Good luck! thanks -mike
Re: winetest, winrash and new volunteers
Paul Vriens wrote: I don't want to go into a discussion about the fact that 'running as a service' and 'on a visible desktop' can/cannot live together properly. Why not? we could have something like windows automatic updates, when new tests are available we pop up and say new tests are ready, run now? and the user can run the tests immediately or later. Like that the testers don't have to check for new tests, but we also run on a visible desktop. Ivan.
[ARTWORK] icon: My Computer
Hi list, I drew a simple icon that COULD be used as a replacement for the current one. I don't know if anyone of you likes it, so please tell me what you think. Tell me if you like it, if you hate if, what could be done better, etc. The icon can be found in different sizes (and in a scalable format) at http://www.egore911.de/vype/wine/ Regards, Christoph Brill aka egore911
Re: Theming for Wine via the registry
--- Mike Hearn [EMAIL PROTECTED] wrote: On Sat, 2005-03-12 at 21:00 +, Oliver Stieber wrote: Ah, that's different. That'd actually require using Gtk/Qt which we cannot do, the best we can get is to look like them. What's the problem, licensing, integration or thread-safety (I know QT isn't thread safe) Well all those *could* be problems, but the real problem is that the Windows widget toolkit and GTK/Qt are too different, you can't map between them. The only problem I can see would be drawing the widgets, I haven't looked deeply enough into QT or GTK to know if it's more on the 'impossible' side of difficult or not. Wrapping the event loop and passing events should be relatively easy. I may have a look at that too, it would be useful if QT/GTK could use some of the existing Windows accessibility software. No, that's not what I meant. Implementing OLE accessibility would mean that Win32 apps on Wine appear to in native tools like at-poke. It wouldn't mean you could use win32 accessibility software to access native apps. That doesn't sound too hard, I don't know how well defined Gnome and QT's accessibility interfaces are but I think QT's coming along quite well it would be nice is everything got Dbused though. Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Theming for Wine via the registry
On Sat, 2005-03-12 at 22:15 +, Oliver Stieber wrote: The only problem I can see would be drawing the widgets, I haven't looked deeply enough into QT or GTK to know if it's more on the 'impossible' side of difficult or not. Wrapping the event loop and passing events should be relatively easy. You have feature mismatches, eg GtkTextBuffer cannot do some things the richedit control can, Win32 menus can't do some things that GTK can etc etc. Also getting the message/paint sync especially for subclassed windows would be impossible. Basically we have to do our own widgets, we can't actually map win32 widgets to some other toolkit. It was tried, back in the early days of the project (to Tk). But it failed. That doesn't sound too hard, I don't know how well defined Gnome and QT's accessibility interfaces are but I think QT's coming along quite well it would be nice is everything got Dbused though. Well the Qt/KDE a11y stuff is integrating with the GNOME APIs, as Sun developed the a11y infrastructure on Linux basically for GNOME. It's based on CORBA and yes it's quite well defined. thanks -mike
Re: Black Text
On Sat, 12 Mar 2005 00:08:01 +0100, Ian Bartelds! [EMAIL PROTECTED] wrote: the gentoo linux version what version would that be ? try posting a wine version number it would mean more. You could also look in the gentoo mm forum , there is a post there with an ebuild for wine-cvs HTH -- Opera 7 mail on Linux
Re: [ARTWORK] icon: My Computer
Just a note: I also added a file icon. Am Samstag, den 12.03.2005, 23:02 +0100 schrieb egore: Hi list, I drew a simple icon that COULD be used as a replacement for the current one. I don't know if anyone of you likes it, so please tell me what you think. Tell me if you like it, if you hate if, what could be done better, etc. The icon can be found in different sizes (and in a scalable format) at http://www.egore911.de/vype/wine/ Regards, Christoph Brill aka egore911
Re: [ARTWORK] icon: My Computer
Am Samstag, den 12.03.2005, 16:34 -0700 schrieb Brian Vincent: On Sun, 13 Mar 2005 00:08:04 +0100, egore [EMAIL PROTECTED] wrote: Am Samstag, den 12.03.2005, 23:02 +0100 schrieb egore: Hi list, I drew a simple icon that COULD be used as a replacement for the current one. I don't know if anyone of you likes it, so please tell me what you think. Tell me if you like it, if you hate if, what could be done better, etc. The icon can be found in different sizes (and in a scalable format) at http://www.egore911.de/vype/wine/ I really like the 128x128 and 64x64. I think they're great. The 32x32 version is hard to distinguish. I think the only reason is because the outline of the computer needs to be in black and maybe the monitor a little smaller. Also, I think we need a 16x16 version more than a 128x128, so it needs to scale small. You're right. I added it in 16x16 to the website. The problem is that the icon is not recognizable at that size. I will check how to tweak them to scale them down (and both ideas you pointed out sound good to me). Ultimately what needs to happen to use them is to insert them as a resource and use the Wine Resource Compiler on them. I think we have a bunch of tools that do this, but I'm not sure. If you read the Developers Guide it will explain this process. However - don't feel like you need to go that far if you're not comfortable with it. I think integration of the icons is a bit early. I think some more wine-devel readers (Alexandre for example) should say if they like them or not and what can be done better. As soon as we can agree on an icon, I will look at the guide and try to use the bunch of tools. At this point we really need some good artists to clean some of our ugly crud up. I will see what I can do :D For instance, the new winecfg tool has a decent logo on the About tab. However it could be a lot nicer - drop shadow inserted or something. I think the logo is much better than the icons from the picker. But I will look at it later. Good work! Thanks :D Chris
Re: [ARTWORK] icon: My Computer
Forgot to mention: I uploaded a Desktop icon. I think it is useable at 16x16, but that's my opinion. Please take a look :D
Re: [ARTWORK] icon: My Computer
On Sat, Mar 12, 2005 at 11:02:54PM +0100, egore wrote: Tell me if you like it, if you hate if, what could be done better, etc. -- The Desktop one is hard to distinguish at 16x16 -- Why the wine glass on the file icon? That can be confusing. -- The My Computer one is a bit busy Maybe we need special versions for the small sizes? -- Dimi.
Scrollkeeper, the documentation, XML, and the way forward
I wanted the Wine documentation to appear on the nice help menus, like other standard apps. I learned that the way to do this is to write an OMF file for each document, which scrollkeeper can then look at to find the metadata about where the document is and how to index it and such. The trouble is, Scrollkeeper and the Gnome help menus no longer support SGML, as XML is the current new and hip thing. The Wine documentation is in SGML. There are quite a few reasons to move forward. The Wine documentation is also a bit separate (requiring its own compiling, for example) from the main code, and this should change. This link: http://scrollkeeper.sourceforge.net/documentation/scrollkeeper_example2_manual/ar01s02.html has some good information about how Wine should look to play well with Scrollkeeper and modern distros. I propose we attack this in phases, and create the following plan of attack: 1) Create a new directory for all XML documentation at wine/doc. This will also bring us to be more standard. 2) When we convert old SGML documents to XML and move them there, we write an OMF file for them then and there (I'll do it if you like). We also make sure the build process is aware of this stuff and is installing the xml and omf files in the right place so scrollkeeper can find them when it runs after build time. 3) We follow the steps at the above link to add scrollkeeper into the configure scripts after we convert the first document to XML. I vote for the Wine User Guide, since I'm working on it. 4) We inform the packagers once scrollkeeper is working in a release, as there are sometimes little tricks for it (one for rpms is on the page) So, beyond that, the first step seems pretty simple: convert the sgml stuff into xml format and put it into the new doc folder. Can someone point me to some good tools to do this? Thanks, Scott Ritchie
Re: winetest, winrash and new volunteers
I can give devel access to winrash cvs to anyone that wants it. I'm too busy to work on this stuff myself these days. Chris On Saturday 12 March 2005 4:48 pm, Ivan Leo Puoti wrote: Paul Vriens wrote: I don't want to go into a discussion about the fact that 'running as a service' and 'on a visible desktop' can/cannot live together properly. Why not? we could have something like windows automatic updates, when new tests are available we pop up and say new tests are ready, run now? and the user can run the tests immediately or later. Like that the testers don't have to check for new tests, but we also run on a visible desktop. Ivan.
Re: [documentation] winedev-kernel
Eric Pouech [EMAIL PROTECTED] wrote: + titleFile management/title + para + With time, Windows API comes closer to the old Unix paradigm Everything + is a file. Even if it grew better over the years, it's still not 100% + there (for example, you cannot use functionReadFile()/function over + a socket handle). Is it really true? From MSDN: BOOL ReadFile( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped ); Parameters hFile [in] Handle to the file to be read. The file handle must have been created with the GENERIC_READ access right. For more information, see File Security and Access Rights. For asynchronous read operations, hFile can be any handle opened with the FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle returned by the socket or accept function. -- Dmitry.
Re: Warcraft 3 - no program start menu found
Juan Lang wrote: I am beginning to I suspect it should really go in dlls/shell32/shellpath.c It is. I think I see where the bug is, and I'm working on it. I should have a patch sometime this weekend, maybe later tonight. I really appreciate you looking at this. Thanks for the patch. -- Tony Lambregts
Re: winetest, winrash and new volunteers
--- Chris Morgan [EMAIL PROTECTED] wrote: winetest to upload the testing results. The winetest building is black magic to me :-) Right now I am interested in the winetest side of things. Like how to get winetest and the server to talk to each other and what is needed in the build and url files. Thanks Steven __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: Warcraft 3 - no program start menu found
--- Tony Lambregts [EMAIL PROTECTED] wrote: I really appreciate you looking at this. Thanks for the patch. No worries, thanks for finding it. That'd been lurking for months, and it was my bug. Glad to flush it out. --Juan __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
