Re: getwinegit.sh 0.2
Christian Lachner wrote: Thanks for your help :D I really don't know if it works on other shells than bash... I hope so but I don't know. The Code is quite clean but the programming could be better (the script was never ment to get this big...). The Compiler-commands are quite easy to be edited. For sure you have already looked at the header at the file ;)) First of all, i will test the script on zsh, csh, old-school-sh. Do you have a BSD-Installation on one of your machines? If not i will fire up vmware and install openbsd this weekend, greeets chris yes I do: I have a FreeBSD 6.0-RELEASE system (200MHz, 32MB of RAM) and a NetBSD 3.0 system (420MHz, 256MB of RAM). Install OpenBSD anyways, could have differences in the 'sh' that are hidden.
DirectX 8 test: Gothic 2 on wine
Hello List! Gothic2 seems to start working with wine. Well - as long as you disable sound in system/gothic.ini. There are some issues with DirectDraw/Direct3D I'd like to report (not sure if they are known): - most textures are missing - everything is really dark (I have to set gamma to 2.5 (via xgamma -gamma 2.5) ) - fonts are missing/crippled I took some pictures and put it together with a log on a simple webpage. Please have a look at http://leidola.newcon.de/gothic2 Thanks a lot for your attention, Ciao, Olaf Leidinger pgpbgcpHJYWD9.pgp Description: PGP signature
Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to
On Friday 24 February 2006 21:23, Alexandre Julliard wrote: > Vitaly Lipatov <[EMAIL PROTECTED]> writes: > > I got follow broken requires when build rpm package: > > > > /usr/bin/../lib/libwine.so.1(WINE_1.0) > > /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0) > > > > and find any methods to disable new feature with rpath when > > I build package. > > It sounds like rpm needs a good whack on the head if it is > unable to cope with this. Anyway, you could always build with > make LDEXERPATH="". Thank you for the solution. Anyway --disable-rpath is more common way for it :) -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!
Re: Debugging
On Friday 24 February 2006 13:46, Stefan Dösinger wrote: > Hi, > > > As such, I'm looking for a little advice on debugging issues when apps > > don't work (yes, I've read what's on winehq.) I have the application > > KeePass (keepass.sourceforge.net) which installs just fine. When I go to > > run it, it just drops me right back to the prompt. > > Pardon my ignorance, but why don't you use the Linux version instead? > http://keepass.sourceforge.net/download.php lists a Linux port. > > If you have the necessary tools to compile keepass, you can build the Win32 > version from source and put a few debugging printfs into it, to see where > it stops. This could shorten the debug time greatly. (Of course this > doesn't work for apps where the source isn't available) No, that's fine. I'm not surprised that somebody knew there was a Linux port. The reason is simple. I'm in the process of trying to put together a presentation for my local LUG on Wine in a couple of months and I'm trying to get to know how to use it better. I also happened to ask a few people what they would like to learn in relation to Wine. One "request" was how to "debug" getting a program to work when it doesn't necessarilly run right out of the box, so to say. In addition, one of the guys told me he tried to run this program under Wine and couldn't get it to work. I tried it and was when I couldn't find any noticable reason for the crash. He's familiar with the Linux port, but it's a version behind and can't read the current database he has all of his information in. It's a valid question. I just thought it'd be a good place for me to start in the realm of trying to get things working because I knew that it would be freely and easily available to anyone on this list so that I might get a little bit of direction. That all. -- -- In a world without fences, who needs Gates? pgpbKEDCi7uu3.pgp Description: PGP signature
Re: Prepare the unicodification of advpack.dll
On 2/24/06, Francois Gouget <[EMAIL PROTECTED]> wrote: > On Fri, 24 Feb 2006, James Hawkins wrote: > > > On 2/24/06, Francois Gouget <[EMAIL PROTECTED]> wrote: > >> > >> All functions that manipulate strings should have an Ansi and a > >> Unicode variant. > > > > Does it matter that native advpack only has Ansi functions? > > That's changing in the latest Windows PSDK. Hence the patch... > Ah darn, more converting work to add to the list. -- James Hawkins
Re: [PATCH] please commit this FCI work
Am Freitag, den 24.02.2006, 14:28 +0100 schrieb Gerold J. Wucherpfennig: > Please commit. I have no knowledge about fci, but some code is strange: +#define fci_set_error(A,B,C) \ +p_fci_internal->perf->erfOper = A; \ +p_fci_internal->perf->erfType = B; \ +p_fci_internal->perf->fError = C; + You use SetLastError() for B almost everywhere following the Macro. Why not add this statement to the Macro? Exceptions where you did not use SetLastError(): Macro-Parameter B is 0 - Did you mean NO_ERROR / ERROR_SUCCESS? - Does Windows use a SetLastError(NO_ERROR) in this case? (Tests for cabinet.dll are only in one file: "extract.c". can you add tests for fci/compress?) When windows does a SetLastError(NO_ERROR): append "SetLastError(B)" to the Macro When windows does not do a SetLastError(NO_ERROR): append "if (B) SetLastError(B)" to the Macro +/* write error */ +fci_set_error( FCIERR_TEMP_FILE, ERROR_WRITE_FAULT, TRUE ); +p_fci_internal->perf->erfType = ERROR_WRITE_FAULT; +p_fci_internal->perf->fError = TRUE; +SetLastError(ERROR_WRITE_FAULT); the two p_pci_* - lines are duplicates (already done in the Macro) btw: What should be added to the changelog? cabinet/fci: cleanup error-handling with a MACRO -- By By ... ... Detlef
Re: WineD3D refcounting fun part II :)
On 24/02/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > remains open is if not unsetting the texture stages is a bug too. Can someone > check on Windows if (a) creating a surface or texture addrefs the > Direct3DDevice, and if (b) assigning a texture to a texture stage addrefs the > Texture? If (a) isn't true, we should unset all texture stages when the > WineD3DDevice is released, if (b) is false we shouldn't do that too. If (a) > and (b) are true, the application is buggy too. I'm sorry that I can't test, > because I've no D3D9-Equipped windows machine available ATM. CreateTexture adds a reference to the device. SetTexture doesn't add a reference to the texture.
Re: WineD3D refcounting fun part II :)
On 24/02/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Are you sure that the Direct3DDevice9 should be released? Windows addrefs the > DirectDraw interface when a surface is created, I'd be surprised if Microsoft > changed that behavior in d3d8 or d3d9. From your description I'd say that > there are still Direct3D9 surfaces hanging, which shouldn't happen. I assume Roderick is talking about the final Release on the d3d device, ie, the one you got from CreateDevice. The surfaces are holding a couple of references to the device, and those should get released when the surface is destroyed, yes. But the application is also holding a single reference to de device. Looking at the trace from the multitexture demo, it appears GetContainer sometimes adds an extra reference to the device. I've submitted a patch for this to wine-patches.
Re: WineD3D refcounting fun part II :)
Hi,
From the multitexture demo:
> void loadTexture( void )
> {
> D3DXCreateTextureFromFile( g_pd3dDevice, "test.bmp", &g_pTexture_0 );
> D3DXCreateTextureFromFile( g_pd3dDevice, "checker.bmp", &g_pTexture_1 );
>
> g_pd3dDevice->SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR);
> g_pd3dDevice->SetSamplerState(0, D3DSAMP_MAGFILTER, D3DTEXF_LINEAR);
> }
Two textures are created
> //-
> // Name: shutDown()
> // Desc:
> //-
> void shutDown( void )
> {
> if( g_pTexture_0 != NULL )
> g_pTexture_0->Release();
>
> if( g_pVertexBuffer != NULL )
> g_pVertexBuffer->Release();
>
> if( g_pd3dDevice != NULL )
> g_pd3dDevice->Release();
>
> if( g_pD3D != NULL )
> g_pD3D->Release();
> }
One texture is released
> void render( void )
> {
>
> g_pd3dDevice->SetTexture( 0, g_pTexture_0 );
> g_pd3dDevice->SetTexture( 1, g_pTexture_1 );
The texture stage is set -> Texure AddRef. The texture isn't unset.
The missing release of the 2nd texture is definitly an application bug. What
remains open is if not unsetting the texture stages is a bug too. Can someone
check on Windows if (a) creating a surface or texture addrefs the
Direct3DDevice, and if (b) assigning a texture to a texture stage addrefs the
Texture? If (a) isn't true, we should unset all texture stages when the
WineD3DDevice is released, if (b) is false we shouldn't do that too. If (a)
and (b) are true, the application is buggy too. I'm sorry that I can't test,
because I've no D3D9-Equipped windows machine available ATM.
pgpe28MHFguYZ.pgp
Description: PGP signature
Re: WineD3D refcounting fun part II :)
Hi, > If you run the test on d3d9 or using oliver's full d3d8 patch, you'll > notice that not all memory is returned when quitting the program. (In > 3dmark2001 this is a big issue as because of this we are out of memory > after running a few demos) The problem appears that wined3d surfaces > contain a reference to the wined3d device. So when you run a game the d3d8 > and wined3d device refcounts are out of sync (the wined3d refcount is a lot > higher because of all the refcounts from the surfaces). Are you sure that the Direct3DDevice9 should be released? Windows addrefs the DirectDraw interface when a surface is created, I'd be surprised if Microsoft changed that behavior in d3d8 or d3d9. From your description I'd say that there are still Direct3D9 surfaces hanging, which shouldn't happen. It could be that some surfaces(or textures) are in use by the WineD3DDevice, for example they are set as textures with IWineD3DDevice::SetTexture. Settexure addrefs the texture interface, which makes sense and is done by Windows too. This means that the textures must be unset before the surfaces and the device can be destroyed, if an app doesn't do so, I'd consider it buggy. I'll look at the multitexture demo, and I'll get an IRC client running. I've never used IRC before(shame on me), but I think it makes discussing this easier. Stefan pgpHd4aa2Q9u4.pgp Description: PGP signature
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Fri, 24 Feb 2006 10:48:47 -0800 Lei Zhang <[EMAIL PROTECTED]> wrote: > On Friday 24 February 2006 04:39 am, Phil Krylov wrote: > > On Fri, 24 Feb 2006 12:24:45 +0100 > > > > Alexandre Julliard <[EMAIL PROTECTED]> wrote: > > > Phil Krylov <[EMAIL PROTECTED]> writes: > > > > On Tue, 21 Feb 2006 14:08:38 -0800 > > > > > > > > Lei Zhang <[EMAIL PROTECTED]> wrote: > > > >> Hi Phil, > > > >> > > > >> Ya, it's a typo. Thanks for catching it. > > > > > > > > Could you kindly fix it then? As this patch was accepted unfixed. > > > > > > I accepted the patch because I don't see how pCurItem could be NULL > > > in that loop (or rather, it could be NULL, but in that case we'll > > > crash before coming back to the loop test). Am I missing something? > > > > Yes, you're right. It can't be NULL because of an earlier test: > > > > para->member.para.nCharOfs + item->member.run.nCharOfs + nEnd - nLen > > >= nMin > > > > But this is very inevident. > > > > -- Ph. > > Hi Phil, Alex > > Yes, it can become NULL, here's how: > > Inside while (ME_CharCompare(pCurItem-> ) > the last if() block assigns a new value to pCurItem, which may be NULL. It may but it won't... ME_FindItemBack(pCurItem) will return NULL only if pCurItem is the first text run in the document. But the if() condition (nCurEnd - nMatched == 0) is TRUE only if the search string is longer than nCurEnd. This does not happen for the first document run because of the condition of the exterior loop which checks if we have enough characters for comparison. --Ph.
Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to
> To be strictly, there is no needs in rpath using if libwine placed in > standard place as /usr/lib > > I got follow broken requires when build rpm package: > > /usr/bin/../lib/libwine.so.1(WINE_1.0) > /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0) Is that an error during building of the rpm, or during installing it? Could you post the exact message and the .spec file used to build it? I reckon there's other software out there that does the same thing and somehow rpm handles it fine . . . Interesting. Kuba
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Friday 24 February 2006 04:39 am, Phil Krylov wrote: > On Fri, 24 Feb 2006 12:24:45 +0100 > > Alexandre Julliard <[EMAIL PROTECTED]> wrote: > > Phil Krylov <[EMAIL PROTECTED]> writes: > > > On Tue, 21 Feb 2006 14:08:38 -0800 > > > > > > Lei Zhang <[EMAIL PROTECTED]> wrote: > > >> Hi Phil, > > >> > > >> Ya, it's a typo. Thanks for catching it. > > > > > > Could you kindly fix it then? As this patch was accepted unfixed. > > > > I accepted the patch because I don't see how pCurItem could be NULL > > in that loop (or rather, it could be NULL, but in that case we'll > > crash before coming back to the loop test). Am I missing something? > > Yes, you're right. It can't be NULL because of an earlier test: > > para->member.para.nCharOfs + item->member.run.nCharOfs + nEnd - nLen > >= nMin > > But this is very inevident. > > -- Ph. Hi Phil, Alex Yes, it can become NULL, here's how: Inside while (ME_CharCompare(pCurItem-> ) the last if() block assigns a new value to pCurItem, which may be NULL. Sorry I didn't patch this earlier, I'll do it today. - Lei
Re: Debugging
Hi, > As such, I'm looking for a little advice on debugging issues when apps > don't work (yes, I've read what's on winehq.) I have the application > KeePass (keepass.sourceforge.net) which installs just fine. When I go to > run it, it just drops me right back to the prompt. Pardon my ignorance, but why don't you use the Linux version instead? http://keepass.sourceforge.net/download.php lists a Linux port. If you have the necessary tools to compile keepass, you can build the Win32 version from source and put a few debugging printfs into it, to see where it stops. This could shorten the debug time greatly. (Of course this doesn't work for apps where the source isn't available) pgpbivqpVxm4Q.pgp Description: PGP signature
Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to
Vitaly Lipatov <[EMAIL PROTECTED]> writes: > To be strictly, there is no needs in rpath using if libwine placed in > standard > place as /usr/lib > > I got follow broken requires when build rpm package: > > /usr/bin/../lib/libwine.so.1(WINE_1.0) > /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0) > > and find any methods to disable new feature with rpath when I build package. It sounds like rpm needs a good whack on the head if it is unable to cope with this. Anyway, you could always build with make LDEXERPATH="". -- Alexandre Julliard [EMAIL PROTECTED]
Re: Palm Desktop conduits through Wine?
Am Freitag, 24. Februar 2006 04:29 schrieb Rich Gilson: > Has there every been any luck/attempts at running Palm Desktop conduits > through wine? I'd drop Palm Desktop altogether, but I have Documents-To-Go > and Passwords Plus, which both only run through Palm Desktop. You can write a sort of Palm Desktop replacement, which loads the conduit dlls and offers the Palm Desktop API to them. The calls can be forwarded to a Linux app, e.g. pilot-link. This way you can replace Palm Desktop by pilot-link + a Winelib app which links the conduit and pilot-link. I think such a program/lib would be out of Wine's scope, as Palm Desktop isn't a part of Windows, instead it would belong more to pilot-link. I've played with this idea some time ago, but I dropped it because of a lack of time. Palm Desktop sort of works in Wine. You can't run the Palm.exe app, but hotsync works. USB doesn't work, but you can do a network sync. Configure your palm to sync with 127.0.0.1, tell hotsync to listen to that port, and start pi-nredir(part of pilot-link) to forward the USB connection to the network. Installing Palm Desktop is not easy, because you need to install MSIE 6. Documents-To-Go needed a native Microsoft Installer the last time I installed it. This was a few months ago, so this is most likely not true today. (If you search the mailing list archives, you'll find a more detailed description) Syncing works quite good, the biggest problem I found was that DocsToGo doesn't support the OpenOffice formats, so I had to convert all documents to the MS Office format and vice versa. The ultimate solution would be a replacement for the DocsToGo application which understands OpenDocument. Or to ask DataViz for a Linux converter ;) pgp5rwYN22Kwb.pgp Description: PGP signature
Re: Prepare the unicodification of advpack.dll
On Fri, 24 Feb 2006, James Hawkins wrote: On 2/24/06, Francois Gouget <[EMAIL PROTECTED]> wrote: All functions that manipulate strings should have an Ansi and a Unicode variant. Does it matter that native advpack only has Ansi functions? That's changing in the latest Windows PSDK. Hence the patch... -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: Problem with virtual memory rlimits
Marcus Meissner <[EMAIL PROTECTED]> writes: > If you limit the virtual memory size using "ulimit -v 140" for > instance, wine will only crash. > > The problem is, that VIRTUAL_alloc_teb() tries to allocate a memory > area within the acceptable userspace ... but it does so much mmap()s > that it runs out of available mmap space before. > > I was only able to reproduce this on AMD64 machines up to now, > which pass out memory starting from 0xf7fff somewhere. > > Any clue how to solve this? I don't think you can. We are using MAP_NORESERVE, which could be argued should not count against the limit, but if it does then we need a limit high enough to reserve everything above 0x8000. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to
В сообщении от 24 февраля 2006 20:53 Alexandre Julliard написал(a): > Vitaly Lipatov <[EMAIL PROTECTED]> writes: > > We need a --disable-rpath option in configure for rpath disable. > > Rpaths is not useful when WINE building for distribution. > > Why is it not useful? Sorry for my English. It is useful when we run wine from the source tree. To be strictly, there is no needs in rpath using if libwine placed in standard place as /usr/lib I got follow broken requires when build rpm package: /usr/bin/../lib/libwine.so.1(WINE_1.0) /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0) and find any methods to disable new feature with rpath when I build package. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to
Vitaly Lipatov <[EMAIL PROTECTED]> writes: > We need a --disable-rpath option in configure for rpath disable. > Rpaths is not useful when WINE building for distribution. Why is it not useful? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Prepare the unicodification of advpack.dll
On 2/24/06, Francois Gouget <[EMAIL PROTECTED]> wrote: > > All functions that manipulate strings should have an Ansi and a > Unicode variant. Does it matter that native advpack only has Ansi functions? I think we should leave it the way it is, because any application that uses advpack will only know of Ansi API and adding unicode handling adds more complexity and chances for error. -- James Hawkins
Re: getwinegit.sh 0.2
Thanks for your help :D I really don't know if it works on other shells than bash... I hope so but I don't know. The Code is quite clean but the programming could be better (the script was never ment to get this big...). The Compiler-commands are quite easy to be edited. For sure you have already looked at the header at the file ;)) First of all, i will test the script on zsh, csh, old-school-sh. Do you have a BSD-Installation on one of your machines? If not i will fire up vmware and install openbsd this weekend, greeets chris
Re: AOL
You could check on http://appdb.winehq.org to see if others have attempted this and what their results are. Chris On 2/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Would AOL work on WINE? > > I would be really greatful if you could e-mail back directly because I > plaining to move to Linux within the next few days > > Sincely > > Toby > > > >
Re: AOL
On 2/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Would AOL work on WINE? > > I would be really greatful if you could e-mail back directly because I > plaining to move to Linux within the next few days Doubtful, unless WINE knows how to control modems in the way AOL wants. You could use Peng [1] though. You could probably even skip most of those steps if you get a distro that has packages for it. [1] http://www.yolinux.com/TUTORIALS/LinuxTutorialAOL.html -- Travis Watkins http://www.realistanew.com
Re: Fix ExitWindows()
Francois Gouget wrote:
Robert Shearman wrote:
Francois Gouget wrote:
-if (SendMessageTimeoutW( *phwnd,
WM_QUERYENDSESSION, 0, 0, send_flags, INFINITE, &result) && !result)
break;
+if (SendMessageTimeoutW( *phwnd,
WM_QUERYENDSESSION, 0, 0, send_flags, 0, &result))
Was this change deliberate to remove the check of result? If so, I
don't see where else the result of the message can be properly checked.
The result is sent back to the application in the WM_ENDSESSION
message and checked in the if branch to exit the loop, and then again
right outside the loop to abort the Windows shutdown.
if (SendMessageTimeoutW( *phwnd, WM_QUERYENDSESSION,
0, 0, send_flags, 0, &result))
{
DWORD_PTR dummy;
SendMessageTimeoutW( *phwnd, WM_ENDSESSION,
result, 0, send_flags, 0, &dummy );
if (!result) break;
}
}
HeapFree( GetProcessHeap(), 0, list );
if (!result)
return TRUE;
Yes, you are right. I obviously didn't spend enough time reading your patch.
--
Rob Shearman
Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to
We need a --disable-rpath option in configure for rpath disable. Rpaths is not useful when WINE building for distribution. Will I add --disable-rpath of there is a better suggestion? В сообщении от 20 февраля 2006 14:40 Alexandre Julliard написал(a): ... > configure: Use --rpath if supported when building binaries to point to > the relative location of the wine libraries. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
Re: Fix ExitWindows()
Robert Shearman wrote:
Francois Gouget wrote:
-if (SendMessageTimeoutW( *phwnd, WM_QUERYENDSESSION,
0, 0, send_flags, INFINITE, &result) && !result) break;
+if (SendMessageTimeoutW( *phwnd, WM_QUERYENDSESSION,
0, 0, send_flags, 0, &result))
Was this change deliberate to remove the check of result? If so, I don't
see where else the result of the message can be properly checked.
The result is sent back to the application in the WM_ENDSESSION message
and checked in the if branch to exit the loop, and then again right
outside the loop to abort the Windows shutdown.
if (SendMessageTimeoutW( *phwnd, WM_QUERYENDSESSION, 0,
0, send_flags, 0, &result))
{
DWORD_PTR dummy;
SendMessageTimeoutW( *phwnd, WM_ENDSESSION, result,
0, send_flags, 0, &dummy );
if (!result) break;
}
}
HeapFree( GetProcessHeap(), 0, list );
if (!result)
return TRUE;
--
Francois Gouget
[EMAIL PROTECTED]
re: Problems with Sockets and TCL
You wrote: >I've found a bug that can be reproduced with two lines of TCL: Great! Can you post a bug report at http://bugs.winehq.org and cc me on it? Be sure to include a full recipe for reproducing the bug, especially the version of tcl and where to download it. I'm glad to see an ISV interested in supporting Wine like this! Is this official interest, or just something you're trying on the side? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: [PATCH] Implement GetCurrentHwProfileA() fully
Could u plz send the patch to wine-patches
On 2/24/06, Ben Collins <[EMAIL PROTECTED]> wrote:
> I setup Wine mainly to make use of some online poker clients that I use
> a lot. I experienced some known bugs related to advapi32.dll,
> specifically GetCurrentHwProfileA()'s semi-stub.
>
> The first issue was that the szHwProfileGuid was being set to a string
> that was one byte too long. This resulted in it actually being a
> concantenation of szHwProfileGuid and szHwProfileName. Fixing that,
> programs like FullTiltPoker.exe were able to work. The website suggested
> changing the return value to 0 (false), but that was just so things got
> ignored.
>
> The second issue with this function was more related to the hard coding
> of the GUID. Some sites, such as PacificPoker and ParadisePoker, can and
> will kill user access to the site. They do not do this by username, but
> but the Profile GUID (I didn't realize this till I started reading bug
> reports, and checking things). Presumably, this reduces the chance that
> someone simply changes their username. They pretty much block the user's
> system, unless they reinstall, or manually change the GUID.
>
> Because of this, all wine installs by default are not allowed to login
> to these sites (it only took one person to get kicked before the GUID
> was dead).
>
> So, to get things done to my liking, I just bit the bullet and
> implemented GetCurrentHwProfileA() correctly.
>
> The patch below has two parts
>
> 1. Implement GetCurrentHwProfileA() fully. It will read the current
> profile (0x value), and obtain the values from this profile for
> docking state, profile name, and profile GUID.
>
> 2. Add default registry entries for the HWLK\*\IDConfigDB\* values.
>
> This still results in a default profile GUID. If anyone knows a way to
> generate a value for this during wineboot, that's probably the best
> solution.
>
> diff -urN wine-0.9.6/dlls/advapi32/advapi.c
> wine-0.9.6-ben/dlls/advapi32/advapi.c
> --- wine-0.9.6/dlls/advapi32/advapi.c 2006-01-19 14:13:51.0 +
> +++ wine-0.9.6-ben/dlls/advapi32/advapi.c 2006-02-24 02:18:26.0
> +
> @@ -116,11 +116,57 @@
> */
> BOOL WINAPI GetCurrentHwProfileA(LPHW_PROFILE_INFOA pInfo)
> {
> - FIXME("(%p) semi-stub\n", pInfo);
> - pInfo->dwDockInfo = DOCKINFO_DOCKED;
> -
> strcpy(pInfo->szHwProfileGuid,"{12340001-1234-1234-1234-1233456789012}");
> - strcpy(pInfo->szHwProfileName,"Wine Profile");
> - return 1;
> + CHAR profile[32];
> + DWORD type;
> + DWORD size;
> + DWORD ret;
> + DWORD val;
> + HKEY hkey;
> + BOOL profile_result = 0;
> +
> + ret = RegOpenKeyA(HKEY_LOCAL_MACHINE,
> "System\\CurrentControlSet\\Control\\IDConfigDB",
> + &hkey);
> +
> + if (ret != ERROR_SUCCESS)
> + goto profile_error;
> +
> + ret = RegGetValueA(hkey, NULL, "CurrentConfig", RRF_RT_DWORD,
> + &type, &val, &size);
> + if (ret != ERROR_SUCCESS || size != 4 || type != REG_DWORD)
> + goto profile_error;
> +
> + /* At least, I think the profile names are hex */
> + sprintf(profile, "Hardware Profiles\\%04x", (WORD)(val & 0x));
> +
> + /* Set the profile name */
> + size = MAX_PROFILE_LEN;
> + ret = RegGetValueA(hkey, profile, "FriendlyName", RRF_RT_REG_SZ,
> + &type, pInfo->szHwProfileName, &size);
> +
> + if (ret != ERROR_SUCCESS || type != REG_SZ)
> + goto profile_error;
> +
> + /* Now get the GUID of this profile */
> + size = HW_PROFILE_GUIDLEN;
> + ret = RegGetValueA(hkey, profile, "HwProfileGuid", RRF_RT_REG_SZ,
> + &type, pInfo->szHwProfileGuid, &size);
> +
> + if (ret != ERROR_SUCCESS || type != REG_SZ)
> + goto profile_error;
> +
> + /* And finally the docking state */
> + ret = RegGetValueA(hkey, "CurrentDockInfo", "DockingState",
> RRF_RT_DWORD,
> + &type, &pInfo->dwDockInfo, &size);
> +
> + if (ret != ERROR_SUCCESS || size != 4 || type != REG_DWORD)
> + goto profile_error;
> +
> + /* Success */
> + profile_result = 1;
> +
> +profile_error:
> + RegCloseKey(hkey);
> + return profile_result;
> }
>
>
> /**
> diff -urN wine-0.9.6/tools/wine.inf wine-0.9.6-ben/tools/wine.inf
> --- wine-0.9.6/tools/wine.inf 2006-01-19 14:14:43.0 +
> +++ wine-0.9.6-ben/tools/wine.inf 2006-02-24 02:19:19.0 +
> @@ -211,6 +211,23 @@
> HKLM,System\CurrentControlSet\Control\Session
> Manager\Environment,"windir",,"%10%"
> HKLM,System\CurrentControlSet\Control\Session
> Manager\Environment,"winsysdir",,"%11%"
>
> +[IDConfigDB]
> +HKLM,System\CurrentControlSet\Control\IDConfigDB,"CurrentConfig",,0x
> +HKLM,System\Current
[PATCH] Implement GetCurrentHwProfileA() fully
I setup Wine mainly to make use of some online poker clients that I use
a lot. I experienced some known bugs related to advapi32.dll,
specifically GetCurrentHwProfileA()'s semi-stub.
The first issue was that the szHwProfileGuid was being set to a string
that was one byte too long. This resulted in it actually being a
concantenation of szHwProfileGuid and szHwProfileName. Fixing that,
programs like FullTiltPoker.exe were able to work. The website suggested
changing the return value to 0 (false), but that was just so things got
ignored.
The second issue with this function was more related to the hard coding
of the GUID. Some sites, such as PacificPoker and ParadisePoker, can and
will kill user access to the site. They do not do this by username, but
but the Profile GUID (I didn't realize this till I started reading bug
reports, and checking things). Presumably, this reduces the chance that
someone simply changes their username. They pretty much block the user's
system, unless they reinstall, or manually change the GUID.
Because of this, all wine installs by default are not allowed to login
to these sites (it only took one person to get kicked before the GUID
was dead).
So, to get things done to my liking, I just bit the bullet and
implemented GetCurrentHwProfileA() correctly.
The patch below has two parts
1. Implement GetCurrentHwProfileA() fully. It will read the current
profile (0x value), and obtain the values from this profile for
docking state, profile name, and profile GUID.
2. Add default registry entries for the HWLK\*\IDConfigDB\* values.
This still results in a default profile GUID. If anyone knows a way to
generate a value for this during wineboot, that's probably the best
solution.
diff -urN wine-0.9.6/dlls/advapi32/advapi.c
wine-0.9.6-ben/dlls/advapi32/advapi.c
--- wine-0.9.6/dlls/advapi32/advapi.c 2006-01-19 14:13:51.0 +
+++ wine-0.9.6-ben/dlls/advapi32/advapi.c 2006-02-24 02:18:26.0
+
@@ -116,11 +116,57 @@
*/
BOOL WINAPI GetCurrentHwProfileA(LPHW_PROFILE_INFOA pInfo)
{
- FIXME("(%p) semi-stub\n", pInfo);
- pInfo->dwDockInfo = DOCKINFO_DOCKED;
-
strcpy(pInfo->szHwProfileGuid,"{12340001-1234-1234-1234-1233456789012}");
- strcpy(pInfo->szHwProfileName,"Wine Profile");
- return 1;
+ CHAR profile[32];
+ DWORD type;
+ DWORD size;
+ DWORD ret;
+ DWORD val;
+ HKEY hkey;
+ BOOL profile_result = 0;
+
+ ret = RegOpenKeyA(HKEY_LOCAL_MACHINE,
"System\\CurrentControlSet\\Control\\IDConfigDB",
+ &hkey);
+
+ if (ret != ERROR_SUCCESS)
+ goto profile_error;
+
+ ret = RegGetValueA(hkey, NULL, "CurrentConfig", RRF_RT_DWORD,
+ &type, &val, &size);
+ if (ret != ERROR_SUCCESS || size != 4 || type != REG_DWORD)
+ goto profile_error;
+
+ /* At least, I think the profile names are hex */
+ sprintf(profile, "Hardware Profiles\\%04x", (WORD)(val & 0x));
+
+ /* Set the profile name */
+ size = MAX_PROFILE_LEN;
+ ret = RegGetValueA(hkey, profile, "FriendlyName", RRF_RT_REG_SZ,
+ &type, pInfo->szHwProfileName, &size);
+
+ if (ret != ERROR_SUCCESS || type != REG_SZ)
+ goto profile_error;
+
+ /* Now get the GUID of this profile */
+ size = HW_PROFILE_GUIDLEN;
+ ret = RegGetValueA(hkey, profile, "HwProfileGuid", RRF_RT_REG_SZ,
+ &type, pInfo->szHwProfileGuid, &size);
+
+ if (ret != ERROR_SUCCESS || type != REG_SZ)
+ goto profile_error;
+
+ /* And finally the docking state */
+ ret = RegGetValueA(hkey, "CurrentDockInfo", "DockingState",
RRF_RT_DWORD,
+ &type, &pInfo->dwDockInfo, &size);
+
+ if (ret != ERROR_SUCCESS || size != 4 || type != REG_DWORD)
+ goto profile_error;
+
+ /* Success */
+ profile_result = 1;
+
+profile_error:
+ RegCloseKey(hkey);
+ return profile_result;
}
/**
diff -urN wine-0.9.6/tools/wine.inf wine-0.9.6-ben/tools/wine.inf
--- wine-0.9.6/tools/wine.inf 2006-01-19 14:14:43.0 +
+++ wine-0.9.6-ben/tools/wine.inf 2006-02-24 02:19:19.0 +
@@ -211,6 +211,23 @@
HKLM,System\CurrentControlSet\Control\Session
Manager\Environment,"windir",,"%10%"
HKLM,System\CurrentControlSet\Control\Session
Manager\Environment,"winsysdir",,"%11%"
+[IDConfigDB]
+HKLM,System\CurrentControlSet\Control\IDConfigDB,"CurrentConfig",,0x
+HKLM,System\CurrentControlSet\Control\IDConfigDB,"UserWaitInterval",,0x001e
+HKLM,System\CurrentControlSet\Control\IDConfigDB,"IsPortable",,0x
+HKLM,System\CurrentControlSet\Control\IDConfigDB\Alias\,"DockingState",,0x
+HKLM,System\CurrentControlSet\Control\IDConfigDB\Alias\,"Capabilities",,0x
+HKLM,System\Cu
AOL
Would AOL work on WINE? I would be really greatful if you could e-mail back directly because I plaining to move to Linux within the next few days Sincely Toby
Re: Server Requirements
Gomez, Felix wrote: Hello... Does Wine run on CentOS 4 (RHEL4) for IBM zSeries/s390? You may be able to compile wine on this architecture and run Winelib applications ( http://www.winehq.org/site/docs/winelib-guide/index ) but running regular windows applications is a different matter ( http://www.winehq.org/site/docs/wine-faq/index#UNDER-WHAT-PLATFORMS-WILL-WINE-RUN ). Bochs ( http://bochs.sourceforge.net/ ) is your best bet for getting windows applications running I am not sure if anyone has actually tried to get Wine to compile on IBM zSeries/s390, you may be the first. I for one am curious about the results of an attempt. If you do try to compile wine on this machine please let us know the results. -- Tony Lambregts
Problem with virtual memory rlimits
Hi, I am having a problem with virtual ulimits/rlimits. If you limit the virtual memory size using "ulimit -v 140" for instance, wine will only crash. The problem is, that VIRTUAL_alloc_teb() tries to allocate a memory area within the acceptable userspace ... but it does so much mmap()s that it runs out of available mmap space before. I was only able to reproduce this on AMD64 machines up to now, which pass out memory starting from 0xf7fff somewhere. Any clue how to solve this? Ciao, Marcus
Re: WineD3D refcounting fun part II :)
On 24/02/06, Robert Shearman <[EMAIL PROTECTED]> wrote: > I am not at all familiar with the wined3d code, but from what I've seen > discussed here it would seem that wined3d shouldn't keep references to > any objects. Instead the other objects should release the corresponding > wined3d object when they are destroyed. I don't think it does, generally. d3d8/9 objects usually contain a wined3d object that they wrap, and when the reference count of the d3d8/9 object reaches 0 it releases its wined3d object. That works fine as long as the is no relation between the wined3d objects. The moment a wined3d object keeps a reference to another wined3d object there is a problem though, because the d3d8/9 object that wraps that object can be released while there are wined3d objects that still keep a reference to that wined3d object. What I mentioned to Roderick on IRC was not really doing refcounts on wined3d objects, but on the wrapper objects instead. Essentially calling AddRef on a wined3d surface would just increase the reference count on the d3d8/9 surface. When the d3d8/9 object's refcount reaches 0 it just calls the wined3d object's cleanup function directly instead of the release. >From Roderick's post I don't get the impression that that particular issue is the problem here though.
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Fri, 24 Feb 2006 12:24:45 +0100 Alexandre Julliard <[EMAIL PROTECTED]> wrote: > Phil Krylov <[EMAIL PROTECTED]> writes: > > > On Tue, 21 Feb 2006 14:08:38 -0800 > > Lei Zhang <[EMAIL PROTECTED]> wrote: > >> > >> Hi Phil, > >> > >> Ya, it's a typo. Thanks for catching it. > > > > Could you kindly fix it then? As this patch was accepted unfixed. > > I accepted the patch because I don't see how pCurItem could be NULL in > that loop (or rather, it could be NULL, but in that case we'll crash > before coming back to the loop test). Am I missing something? Yes, you're right. It can't be NULL because of an earlier test: para->member.para.nCharOfs + item->member.run.nCharOfs + nEnd - nLen >= nMin But this is very inevident. -- Ph.
Re: Fix ExitWindows()
Francois Gouget wrote: -if (SendMessageTimeoutW( *phwnd, WM_QUERYENDSESSION, 0, 0, send_flags, INFINITE, &result) && !result) break; +if (SendMessageTimeoutW( *phwnd, WM_QUERYENDSESSION, 0, 0, send_flags, 0, &result)) Was this change deliberate to remove the check of result? If so, I don't see where else the result of the message can be properly checked. -- Rob Shearman
Re: WineD3D refcounting fun part II :)
H. Verbeet wrote: I also suspect there might be a couple of circular references in the form of device->stateblock->object->device, but I haven't had time to really look into that yet. I *think* wined3d shouldn't keep references to objects in the device's Set* methods, but I remember that when I removed them in IWineD3DDeviceImpl_SetVertexShader Oliver put them back again in a later patch for some reason. It would be good to write out on paper or otherwise the hierarchy of which lifetimes a given object controls so that you can be sure of this. There should be no loops. I am not at all familiar with the wined3d code, but from what I've seen discussed here it would seem that wined3d shouldn't keep references to any objects. Instead the other objects should release the corresponding wined3d object when they are destroyed. -- Rob Shearman
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
Phil Krylov <[EMAIL PROTECTED]> writes: > On Tue, 21 Feb 2006 14:08:38 -0800 > Lei Zhang <[EMAIL PROTECTED]> wrote: >> >> Hi Phil, >> >> Ya, it's a typo. Thanks for catching it. > > Could you kindly fix it then? As this patch was accepted unfixed. I accepted the patch because I don't see how pCurItem could be NULL in that loop (or rather, it could be NULL, but in that case we'll crash before coming back to the loop test). Am I missing something? -- Alexandre Julliard [EMAIL PROTECTED]
Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT
On Tue, 21 Feb 2006 14:08:38 -0800 Lei Zhang <[EMAIL PROTECTED]> wrote: > On Tuesday 21 February 2006 12:42 pm, you wrote: > > On Tue, 21 Feb 2006 10:19:01 -0800 > > > > Lei Zhang <[EMAIL PROTECTED]> wrote: > > > - while (pCurItem && > > > pCurItem->member.run.strText->szData[nCurEnd - nMatched - 1] == > > > text[nLen - nMatched - 1]) + while > > > (ME_CharCompare(pCurItem->member.run.strText->szData[nCurEnd - > > > nMatched - 1], text[nLen - nMatched - 1], (flags & FR_MATCHCASE))) > > > > You've dropped pCurItem NULL check here. Probably just a typo... > > > > -- Ph. > > Hi Phil, > > Ya, it's a typo. Thanks for catching it. Could you kindly fix it then? As this patch was accepted unfixed. -- Ph.
Re: advpack [1/3]: Factor out loading the advpack API [RESEND]
"James Hawkins" <[EMAIL PROTECTED]> writes:
> @@ -256,21 +268,9 @@ static void translateinfstring_test()
>
> START_TEST(advpack)
> {
> -HMODULE hdll;
> -
> -hdll = LoadLibraryA("advpack.dll");
> -if (!hdll)
> -return;
> -
> -pGetVersionFromFile = (void*)GetProcAddress(hdll, "GetVersionFromFile");
> -pDelNode = (void*)GetProcAddress(hdll, "DelNode");
> -pTranslateInfString = (void*)GetProcAddress(hdll, "TranslateInfString");
> -if (!pGetVersionFromFile || !pDelNode || !pTranslateInfString)
> -return;
> +init_function_pointers();
Why are you removing the pointer checks?
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Debugging
Hi, On Friday 24 February 2006 06:28, Juan Lang wrote: > As far as how to deal with this, try modifying kernel32.spec to add a stub > for BlockInput, like: > @ stub BlockInput > and see if the program gets any further. Hi according to MSDN, BlockInput is a user32.dll function: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputfunctions/blockinput.asp In fact, we do have a commented out stub in dlls/user/user32.spec # @ stub BlockInput Bye, -- Michael Jung [EMAIL PROTECTED]
