Re: [PATCH] seperate AC_CONFIG_FILES.
On Tue, Feb 27, 2007 at 01:03:09AM +0100, Detlef Riekenberg wrote: > On Mo, 2007-02-26 at 22:06 +0100, Marcus Meissner wrote: > > > -AC_CONFIG_FILES([ > > -Make.rules > > -dlls/Makedll.rules > > -dlls/Makeimplib.rules > > -dlls/Maketest.rules > > -programs/Makeprog.rules > > -Makefile > > -dlls/Makefile > > Does "tools/make_makefiles" still work after your Patch? > - for a new dll > - for a new test > - for a new program > > I'm unable to test that here (my autoconf is to old) Seems I need to actually change tools/make_makefiles instead of configure.ac :( Ciao, Marcus
Re: configure: Break single-line ac_config_files list into multiple lines.
On Sat, Feb 24, 2007 at 02:15:29PM +0200, Saulius Krasuckas wrote: > This long line breaks automated rebasing of one of testing branches on > (namely ntoskrnl) on my box every time a new dll or program is added. > That's because I need to merge conflict for this line by my hand. You might find http://wiki.winehq.org/There_are_always_conflicts_in_configure interesting. Jan
Re: GDI surfaces, GDI heap and wined3d's VideoMemorySize
On Sunday 25 February 2007 03:36:02 pm Vitaliy Margolen wrote: > The memory size setting is only in registry because you should not touch > it in the first place. I thought it was added to the registry because Wine can't figure out the video memory amount itself from OpenGL or X, and that allows the user to make it report the proper amount (or at least, more proper). Before it was hard-coded to 64MB.
Re: kernel32: Implement ReplaceFileA/ReplaceFileW
Erich Hoover wrote: Is the attached more like what you're looking for? I did some investigation and... actually I'm looking for an equivalent to the linux splice syscall. Win32 is the most braindead API ever. Duh. The "right" way would probably to do the copying yourself by read/write.. but I dunno. Your code looks solid at the first glance. Three things: - I'd remove the FILE_SHARE_DELETE and FILE_SHARE_WRITE. - Use MoveFile instead of CopyFile/DeleteFile at the end? - Are you sure you're supposed to set ERROR_INVALID_PARAMETER no matter what bad happens? If the function which failed already set LE you should probably keep it... Felix
Re: [7/12] WineD3D: Select an onscreen context based on the thread
Am Montag 26 Februar 2007 13:49 schrieb Stefan Dösinger: Alexandre, do not patch 7, 8 and 9 yet, they are reported to cause regressions. Patch 10, 11 and 12 should apply without them too. pgpJTkrrhpZ8P.pgp Description: PGP signature
Re: [PATCH] seperate AC_CONFIG_FILES.
On Mo, 2007-02-26 at 22:06 +0100, Marcus Meissner wrote: > -AC_CONFIG_FILES([ > -Make.rules > -dlls/Makedll.rules > -dlls/Makeimplib.rules > -dlls/Maketest.rules > -programs/Makeprog.rules > -Makefile > -dlls/Makefile Does "tools/make_makefiles" still work after your Patch? - for a new dll - for a new test - for a new program I'm unable to test that here (my autoconf is to old) -- By by ... Detlef
Re: [1/12] - [12/12] WineD3D (multithreading)
Am Montag 26 Februar 2007 22:52 schrieb Mirek: > Stefan Dösinger napsal(a): > > Am Montag 26 Februar 2007 19:58 schrieb Mirek: > >> Hi, this series of patches broke some textures in TES IV: Oblivion, > >> should I create bug in winebugs? I tried some other apps, they looks ok. > >> (bug is here after patch 7/12 and 8/12). > > > > Which patch breaks oblivion? Can you describe the kind of breakage? > > > > *cough* That game seems to be really picky *cough* > > Patch number 7 and 8 (after patch 7 game crashed, after patch 8 it works > normal but with graphical problems). I have Core 2 Duo CPU and SMP > enabled, Nvidia GF6800GS with latest stable drivers. > > Here are some screenshots: > http://headline.czela.net/Mirek/wine/TES%20IV:%20Oblivion/regression/ > > 2007-02-26-224223.jpg is for comparsion. > > This is realy strange, because after I do some spells (graphical efects) > in game it just recover to normal state (everything looks like before). Strange yes. Does it print any fixme right before it crashes if you only apply patch 7? pgpG6PnLunRc5.pgp Description: PGP signature
Re: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend)
On 2/26/07, Andrew Talbot <[EMAIL PROTECTED]> wrote: James Hawkins wrote: > On 2/26/07, Andrew Talbot <[EMAIL PROTECTED]> wrote: >> What is wrong with this patch, please? >> > > This isn't how it's defined in the SDK headers. > Am I right in thinking that for non-embedded-CE versions of Windows the lpHeaderInfo variable of CommitURLCacheEntry() is now a LPCTSTR? In which case, I presume that the comment about the ascii version requiring a LPBYTE is now wrong: the "A" version should now have a LPCSTR and the "W" version, a LPCWSTR. #ifndef USE_FIXED_COMMIT_URL_CACHE_ENTRY // Temporary state of affairs until we reconcile our apis. // Why are we doing this? HeaderInfo _should_ be string data. // However, one group is passing binary data instead. For the // unicode api, we've decided to disallow this, but this // brings up an inconsistency between the u and a apis, which // is undesirable. // For Beta 1, we'll go with this behaviour, but in future releases // we want to make these apis consistent. BOOLAPI CommitUrlCacheEntryA( __in LPCSTR lpszUrlName, __in_opt LPCSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaderSize) LPBYTE lpHeaderInfo, __in_opt DWORD dwHeaderSize, __reserved LPCSTR lpszFileExtension, __in_opt LPCSTR lpszOriginalUrl ); BOOLAPI CommitUrlCacheEntryW( __in LPCWSTR lpszUrlName, __in_opt LPCWSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaders) LPWSTR lpszHeaderInfo, __in DWORD dwHeaders, __reserved LPCWSTR lpszFileExtension, __in_opt LPCWSTR lpszOriginalUrl ); #ifdef UNICODE #define CommitUrlCacheEntry CommitUrlCacheEntryW #else #define CommitUrlCacheEntry CommitUrlCacheEntryA #endif #else CommitUrlCacheEntryA( __in LPCSTR lpszUrlName, __in_opt LPCSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaderSize) LPCSTR lpHeaderInfo, __in DWORD dwHeaderSize, __reserved LPCSTR lpszFileExtension, __in_opt LPCSTR lpszOriginalUrl ); CommitUrlCacheEntryW( __in LPCWSTR lpszUrlName, __in_opt LPCWSTR lpszLocalFileName, __in FILETIME ExpireTime, __in FILETIME LastModifiedTime, __in DWORD CacheEntryType, __in_ecount_opt(dwHeaderSize) LPCWSTR lpHeaderInfo, __in DWORD dwHeaderSize, __reserved LPCWSTR lpszFileExtension, __in_opt LPCWSTR lpszOriginalUrl ); #ifdef UNICODE #define CommitUrlCacheEntry CommitUrlCacheEntryW #else #define CommitUrlCacheEntry CommitUrlCacheEntryA #endif // !UNICODE #endif -- James Hawkins
Re: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend)
Andrew Talbot wrote: > ... but the corresponding parameter of > CommitURLCacheEntry() [...] ought to be a LPTSTR Or rather, a LPCTSTR. So, is there any scope to constify, here? -- A.
Re: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend)
The problem seems to be that the INTERNET_CACHE_ENTRY_INFO structure has a member lpHeaderInfo that is a LPBYTE, but the corresponding parameter of CommitURLCacheEntry() - sorry, I truncated its name in the original posting - ought to be a LPTSTR. It is not yet clear to me what is required. -- Andy.
Re: wininet: Constify a formal parameter of CommitURLCacheEntry{A|W}() (Resend)
James Hawkins wrote: > On 2/26/07, Andrew Talbot <[EMAIL PROTECTED]> wrote: >> What is wrong with this patch, please? >> > > This isn't how it's defined in the SDK headers. > Am I right in thinking that for non-embedded-CE versions of Windows the lpHeaderInfo variable of CommitURLCacheEntry() is now a LPCTSTR? In which case, I presume that the comment about the ascii version requiring a LPBYTE is now wrong: the "A" version should now have a LPCSTR and the "W" version, a LPCWSTR. -- Andy.
Re: Add localizable strings support for popup menu in selection tree control.
On 2/26/07, Крылов Николай <[EMAIL PROTECTED]> wrote:
diff --git a/dlls/msi/dialog.c b/dlls/msi/dialog.c
index 35a192c..3826326 100644
--- a/dlls/msi/dialog.c
+++ b/dlls/msi/dialog.c
@@ -1755,17 +1755,41 @@ msi_seltree_popup_menu( HWND hwnd, INT x
HMENU hMenu;
INT r;
+static const WCHAR szMenuLocal[] =
{'M','e','n','u','L','o','c','a','l',0};
+static const WCHAR szMenuAllLocal[] =
{'M','e','n','u','A','l','l','L','o','c','a','l',0};
+static const WCHAR szMenuAdvertise[] =
{'M','e','n','u','A','d','v','e','r','t','i','s','e',0};
+static const WCHAR szMenuAbsent[] =
{'M','e','n','u','A','b','s','e','n','t',0};
+/* If msi_dialog_get_uitext returns NULL - use default strings: */
+static const WCHAR szMenuLocalDef[] =
{'I','n','s','t','a','l','l',' ','f','e','a','t','u','r','e',' ',
'l','o','c','a','l','l','y',0};
+static const WCHAR szMenuAllLocalDef[] =
{'I','n','s','t','a','l','l',' ','e','n','t','i','r','e','
','f','e','a','t','u','r','e',0};
+static const WCHAR szMenuAdvertiseDef[] =
{'I','n','s','t','a','l','l',' ','o','n',' ','d','e','m','a','n','d',0};
+static const WCHAR szMenuAbsentDef[] = {'D','o','n','\'','t','
','i','n','s','t','a','l','l',0};
+
+LPWSTR szLocal,szAllLocal,szAdvertise,szAbsent;
+struct msi_selection_tree_info *info;
+
+info = GetPropW(hwnd, szButtonData);
+
+szLocal= msi_dialog_get_uitext( info->dialog, szMenuLocal );
+szAllLocal= msi_dialog_get_uitext( info->dialog, szMenuAllLocal );
+szAdvertise= msi_dialog_get_uitext( info->dialog, szMenuAdvertise
);
+szAbsent= msi_dialog_get_uitext( info->dialog, szMenuAbsent );
+
/* create a menu to display */
hMenu = CreatePopupMenu();
-/* FIXME: load strings from resources */
-AppendMenuA( hMenu, MF_ENABLED, INSTALLSTATE_LOCAL, "Install
feature locally");
-AppendMenuA( hMenu, MF_GRAYED, 0x1000, "Install entire feature");
-AppendMenuA( hMenu, MF_ENABLED, INSTALLSTATE_ADVERTISED, "Install
on demand");
-AppendMenuA( hMenu, MF_ENABLED, INSTALLSTATE_ABSENT, "Don't
install");
+/* Use strings from resources */
+AppendMenuW( hMenu, MF_ENABLED, INSTALLSTATE_LOCAL,
(szLocal==NULL)?szMenuLocalDef:szLocal );
+AppendMenuW( hMenu, MF_GRAYED, 0x1000,
(szAllLocal==NULL)?szMenuAllLocalDef:szAllLocal );
+AppendMenuW( hMenu, MF_ENABLED, INSTALLSTATE_ADVERTISED,
(szAdvertise==NULL)?szMenuAdvertiseDef:szAdvertise );
+AppendMenuW( hMenu, MF_ENABLED, INSTALLSTATE_ABSENT,
(szAbsent==NULL)?szMenuAbsentDef:szAbsent );
r = TrackPopupMenu( hMenu, TPM_LEFTALIGN | TPM_TOPALIGN |
TPM_RETURNCMD,
x, y, 0, hwnd, NULL );
DestroyMenu( hMenu );
+if(szLocal) msi_free(szLocal);
+if(szAllLocal) msi_free(szAllLocal);
+if(szAdvertise) msi_free(szAdvertise);
+if(szAbsent) msi_free(szAbsent);
return r;
}
Don't check values for NULL before freeing them. The check is
redundant, and we spent a long time removing such checks.
--
James Hawkins
Re: kernel32: Implement ReplaceFileA/ReplaceFileW
I assume you're referring to the file existence check and file delete, followed by the actual copy and move. I implemented these checks in this manner in order to provide error codes consistent with the documentation. I am not incredibly familiar with the Wine internals, but it looks to me like the functions called should handle a simultaneous call from another thread (without unnecessary code duplication). For example, if the "replaced" file goes missing between the check and the CopyFileW call then CopyFileW will return an error. If the "replaced" file appears between the DeleteFileW call and the MoveFileExW call (since the MOVEFILE_REPLACE_EXISTING flag is not set), then the MoveFileExW call will fail. The documentation's expected error codes for ReplaceFile seem to be consistent with these potential outcomes. I apologize if there's something I'm missing here, please let me know. Erich Hoover [EMAIL PROTECTED] On 2/26/07, Felix Nawothnig <[EMAIL PROTECTED]> wrote: Erich Hoover wrote: > Real Name: > Erich Hoover > Description: > Implements the functions ReplaceFileA and ReplaceFileW in kernel32 > (Bug #7544). Also provides conformance test code to ensure proper > functionality. > Changelog: > kernel32: Implement ReplaceFileA/ReplaceFileW Your patch seems to introduce lots of race cons. It's possible these exist on Win32 too but can't we avoid them?
Re: [1/12] - [12/12] WineD3D (multithreading)
Stefan Dösinger napsal(a): Am Montag 26 Februar 2007 19:58 schrieb Mirek: Hi, this series of patches broke some textures in TES IV: Oblivion, should I create bug in winebugs? I tried some other apps, they looks ok. (bug is here after patch 7/12 and 8/12). Which patch breaks oblivion? Can you describe the kind of breakage? *cough* That game seems to be really picky *cough* Patch number 7 and 8 (after patch 7 game crashed, after patch 8 it works normal but with graphical problems). I have Core 2 Duo CPU and SMP enabled, Nvidia GF6800GS with latest stable drivers. Here are some screenshots: http://headline.czela.net/Mirek/wine/TES%20IV:%20Oblivion/regression/ 2007-02-26-224223.jpg is for comparsion. This is realy strange, because after I do some spells (graphical efects) in game it just recover to normal state (everything looks like before).
Re: kernel32: Implement ReplaceFileA/ReplaceFileW
Erich Hoover wrote:
I assume you're referring to the file existence check and file delete,
followed by the actual copy and move. I implemented these checks in
this manner in order to provide error codes consistent with the
documentation. I am not incredibly familiar with the Wine internals,
but it looks to me like the functions called should handle a
simultaneous call from another thread (without unnecessary code
duplication). For example, if the "replaced" file goes missing between
the check and the CopyFileW call then CopyFileW will return an error.
If the "replaced" file appears between the DeleteFileW call and the
MoveFileExW call (since the MOVEFILE_REPLACE_EXISTING flag is not set),
then the MoveFileExW call will fail. The documentation's expected error
codes for ReplaceFile seem to be consistent with these potential
outcomes.
Reading MSDN that doesn't seem to be the case. The way I see it all
those errors documented could be caused by file permisions. MSDN doesn't
say anything about race cons.
Some notes about the patch:
+/* Maker sure the "replacement" file exists before continuing */
+if(!RtlDoesFileExists_U( lpReplacementFileName ))
+{
+SetLastError(ERROR_INVALID_PARAMETER);
+return FALSE;
+}
This would probably the right place to lock the file...
+/*
+ * If the user wants a backup then that needs to be performed first
+ * * Do not fail to backup if "replaced" does not exist
+ */
+if( lpBackupFileName && RtlDoesFileExists_U( lpReplacedFileName ) )
The call to RtlDoesFileExists_U() is redundant and introduces a race
con. CopyFileW() will check for existence, check GLE afterwards.
+{
+/* If an existing backup exists then copy over it */
+ */
+if(!CopyFileW( lpReplacedFileName, lpBackupFileName, FALSE ))
+{
+SetLastError(ERROR_INVALID_PARAMETER);
+return FALSE;
+}
+}
+/*
+ * Now that the backup has been performed (if requested), copy the
replacement
+ * into place (make sure we can delete the original file first)
+ * * Do not fail if "replaced" does not exist
+ */
+if(RtlDoesFileExists_U( lpReplacedFileName ) && !DeleteFileW(
lpReplacedFileName ))
Same here, DeleteFile() will check for existence.
+{
+SetLastError(ERROR_UNABLE_TO_REMOVE_REPLACED);
+return FALSE;
+}
+if(!MoveFileExW( lpReplacementFileName, lpReplacedFileName, flags ))
Couldn't you just get rid of the DeleteFile, check why MoveFileEx()
failed and get rid of the call to RtlDoesFileExists_U(lpReplacedFileName)?
+{
+SetLastError(ERROR_UNABLE_TO_MOVE_REPLACEMENT);
+return FALSE;
+}
+/* All done, file replacement successful */
+return TRUE;
Re: wininet: Constify a formal parameter of CommitURLCache{A|W}() (Resend)
On 2/26/07, Andrew Talbot <[EMAIL PROTECTED]> wrote: What is wrong with this patch, please? This isn't how it's defined in the SDK headers. -- James Hawkins
Re: [1/12] - [12/12] WineD3D (multithreading)
Am Montag 26 Februar 2007 19:58 schrieb Mirek: > Hi, this series of patches broke some textures in TES IV: Oblivion, > should I create bug in winebugs? I tried some other apps, they looks ok. > (bug is here after patch 7/12 and 8/12). Which patch breaks oblivion? Can you describe the kind of breakage? *cough* That game seems to be really picky *cough* pgpNQwINFXcpo.pgp Description: PGP signature
Re: kernel32: Implement ReplaceFileA/ReplaceFileW
Erich Hoover wrote: Real Name: Erich Hoover Description: Implements the functions ReplaceFileA and ReplaceFileW in kernel32 (Bug #7544). Also provides conformance test code to ensure proper functionality. Changelog: kernel32: Implement ReplaceFileA/ReplaceFileW Your patch seems to introduce lots of race cons. It's possible these exist on Win32 too but can't we avoid them?
Re: GDI surfaces, GDI heap and wined3d's VideoMemorySize
Robert Shearman <[EMAIL PROTECTED]> writes: > CreateCompatibleDC should be made to fail if the CreateRectRgn call fails. Yes, I committed a fix for that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [1/12] - [12/12] WineD3D (multithreading)
Hi, this series of patches broke some textures in TES IV: Oblivion, should I create bug in winebugs? I tried some other apps, they looks ok. (bug is here after patch 7/12 and 8/12). Mirek
Re: xcopy try 3
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> writes: > diff --git a/programs/xcopy/Makefile.in b/programs/xcopy/Makefile.in > new file mode 100755 All the files you create or modify are marked executable, could you please fix that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: GDI surfaces, GDI heap and wined3d's VideoMemorySize
Rok Mandeljc wrote: Hey all, I've been experiencing an odd behavior in Baldur's Gate 2; when "VideoMemorySize" registry key for wined3d is set to anything greater than 64MB (69MB, actually), it stops before playing intro movie, printing following line: err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. Tracing the source of issue by inserting custom traces I got the following: IDirectDrawImpl_CreateNewSurface -> IWineD3DDeviceImpl_CreateSurface (decides to use GDI surface) -> IWineGDISurfaceImpl_PrivateSetup -> IWineD3DSurfaceImpl_GetDC -> CreateCompatibleDC -> CreateRectRgn -> REGION_CreateRegion -> GDI_AllocObject -> alloc_large_heap alloc_large_heap fails because it can't find next large handle and returns NULL, which is passed up the chain, where CreateCompatibleDC puts it in dc->hVisRgn. Then DC_InitDC is called with that dc, which calls CLIPPING_UpdateGCRegion, and that one finally chokes on it, printing afore-mentioned line and calling exit(1). Now, when the game is run with 64MB of VideoMemorySize, upon reaching the same point, IDirectDrawImpl_CreateNewSurface returns WINED3DERR_OUTOFVIDEOMEMORY (because of "IWineD3DDevice_GetAvailableTextureMem(iface) <= _size" check in D3DCREATERESOURCEOBJECTINSTANCE macro) and intro movie starts playing. So it seems Baldur's Gate 2 is trying to create as many surfaces as possible before running out of memory. And the problem arises when specified memory size is large enough to take up all GDI's heap... Sorry for the long-winded description of the problem, but I'm not sure where and how this should be fixed (is it wined3d issue or should GDI have its heap enlarged?), otherwise I'd do it myself... CreateCompatibleDC should be made to fail if the CreateRectRgn call fails. -- Rob Shearman
wine or wine-preloader exit with code 2 on x86_64
Hello, I have build wine with the help of wiki WineOn64bit LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure --prefix=/opt/wine --datadir=/usr/share But wine or wine-preloader always return 2 as you can see : [EMAIL PROTECTED] wine-0.9.31]# loader/wine-preloader [EMAIL PROTECTED] wine-0.9.31]# echo $? 2 [EMAIL PROTECTED] wine-0.9.31]# ./wine --version [EMAIL PROTECTED] wine-0.9.31]# echo $? 2 Anyone can help please ? See you, Escuder Nicolas
Re: wine and msys rxvt.exe
On 26/02/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: "Wesley Parish" <[EMAIL PROTECTED]> wrote: > failed to load libX11.dll Looks like rxvt.exe is linked to an MSys provided X11 libraries that require a Windows X11 sever to be present and running. That's a sort of layer on layer and I don't think that there is someone who wants to make this configuration work. AFAIR MSys's rxvt.exe uses libW11.dll, which implements Xlib API on top of Win32 USER/GDI (no extra X server). However, it could be still difficult (probably because of API name clashes?) Not sure why the message is about libX11.dll - probably it sees $DISPLAY and tries to use real X? -- Ph.
Re: Wine and XP Themes
Frank Richter wrote: WRT speed: themes usually use alpha-blending extensively; however, the speed of Wine's AlphaBlend() can almost be measured in geological terms; Why is that? Looking at it it seems to be using XRender - since theming doesn't require Aero and stuff what way would there be to speed it up? (I admit I didn't really read the code. :) Felix
Re: [9/12] WineD3D: When multithreading, call glFinish after drawing
Would GL_NV_fence be usefull here?
Re: Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions
Robert Shearman <[EMAIL PROTECTED]> writes: > Yes, the table windows in the query designer in Access 2003. Access > 2003 works on Windows 2000+. Maybe it's NT4 that doesn't send them then. Anyway, if the app needs them I don't have a problem with adding them back. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [3/12 WineD3D/DDraw: Forward DDSCL_MULTITHREADED to WineD3D
On 26/02/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Note: that this patch conflicts with the ddraw thread safety patch. After this patch here is applied, I will send an updated thread safety patch for the ddraw implementation What exactly is this supposed to fix? We already pass the behaviour flags through to IWineD3DImpl_CreateDevice(), so shouldn't wined3d just handle it there?
Re: GDI surfaces, GDI heap and wined3d's VideoMemorySize
Am Sonntag 25 Februar 2007 21:57 schrieb Rok Mandeljc: > Hey all, > Now, when the game is run with 64MB of VideoMemorySize, upon reaching > the same point, IDirectDrawImpl_CreateNewSurface returns > WINED3DERR_OUTOFVIDEOMEMORY (because of > "IWineD3DDevice_GetAvailableTextureMem(iface) <= _size" check in > D3DCREATERESOURCEOBJECTINSTANCE macro) and intro movie starts playing. > So it seems Baldur's Gate 2 is trying to create as many surfaces as > possible before running out of memory. And the problem arises when > specified memory size is large enough to take up all GDI's heap... Now that seems interesting. Actually, I have never had a 2D application creating that much surfaces, and the old ddraw code only advertised 8 mb of mem. It might be an out of memory somewhere, but not sure how and why. You could try opengl surfaces. Those do not have a DIB section, unless the app calls GetDC on the surface
Re: Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions
Alexandre Julliard wrote: Robert Shearman <[EMAIL PROTECTED]> writes: Hi Alexandre, A patch of yours from 2.5 years ago (http://source.winehq.org/git/wine.git/?a=commitdiff;h=b72994b6d4a04352e18934cd3fbe51749b7da234) changed the behaviour to not send WM_GETTEXT any more. My experiments on Windows show that WM_GETTEXT should be used. Can you remember what the reasoning behind the change in this patch was? Probably to avoid potential deadlocks; I'm not sure there's one correct way, IIRC Win2k doesn't send them but XP does. Do you have something that depends on receiving them? Yes, the table windows in the query designer in Access 2003. Access 2003 works on Windows 2000+. -- Rob Shearman
Re: Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions
Robert Shearman <[EMAIL PROTECTED]> writes: > Hi Alexandre, > > A patch of yours from 2.5 years ago > (http://source.winehq.org/git/wine.git/?a=commitdiff;h=b72994b6d4a04352e18934cd3fbe51749b7da234) > changed the behaviour to not send WM_GETTEXT any more. My experiments > on Windows show that WM_GETTEXT should be used. Can you remember what > the reasoning behind the change in this patch was? Probably to avoid potential deadlocks; I'm not sure there's one correct way, IIRC Win2k doesn't send them but XP does. Do you have something that depends on receiving them? -- Alexandre Julliard [EMAIL PROTECTED]
Using InternalGetWindowText Instead of Sending WM_GETTEXT when Drawing Window Captions
Hi Alexandre, A patch of yours from 2.5 years ago (http://source.winehq.org/git/wine.git/?a=commitdiff;h=b72994b6d4a04352e18934cd3fbe51749b7da234) changed the behaviour to not send WM_GETTEXT any more. My experiments on Windows show that WM_GETTEXT should be used. Can you remember what the reasoning behind the change in this patch was? -- Rob Shearman
Re: [2/4 revised] msi: Expand IDL file to contain all OLE automation interfaces.
On Sun, 2007-02-25 at 22:51 -0600, James Hawkins wrote:
> On 2/25/07, Misha Koshelev <[EMAIL PROTECTED]> wrote:
> > This patch expands the IDL to contain all OLE automation interfaces that
> > the freely downloadable MS Windows Installer contains, and adds a
> > msiserver_dispids.h file that has define statements for all the dispids.
> >
> > Changelog:
> >
> > * msi: Expand IDL file to contain all OLE automation interfaces.
> >
>
> * Copyright (C) 2007 Mike McCormack
> + *Misha Koshelev
>
> You have to repeat the Copyright (C) 2007 part for your name.
It seems from doing a find . -name \*.idl -exec head {} \; -print that
you are generally correct, but the formatting for copyright notices does
vary. dlls/stdole32.tlb/std_ole_v1.idl and std_ole_v2.idl in that
directory has:
/*
* Copyright (C) 2003 Robert Shearman
* 2005 Huw Davies
which is where I got the idea to do mine that way in the first place.
>
> +[id(DISPID_INSTALLER_OPENDATABASE)]
> +Database* OpenDatabase(
> + [in] BSTR
> DatabasePath,
> + [in]
> VARIANT OpenMode);
> +[id(DISPID_INSTALLER_SUMMARYINFORMATION), propget]
> +SummaryInfo* SummaryInformation(
> +
> [in] BSTR PackagePath,
> +
> [in, optional, defaultvalue(0)] long UpdateCount);
> +[id(DISPID_INSTALLER_ENABLELOG)]
> +void EnableLog(
> + [in] BSTR LogMode,
> + [in] BSTR LogFile);
>
> Did you copy and paste this from OleView? This formatting is ridiculous.
>
Re: comctl32: rebar[2/3]: WM_SETFONT should send a RBN_HEIGHTCHANGED if necessary (with testcase)
Mikołaj Zalewski <[EMAIL PROTECTED]> writes: > This allows as to eliminate the third parameter of REBAR_Layout. > From 2edae3656159e84a0366b65e1bd1d13e3089dc97 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= <[EMAIL PROTECTED]> > Date: Mon, 19 Feb 2007 20:42:08 +0100 > Subject: [PATCH] comctl32: rebar: WM_SETFONT should send a RBN_HEIGHTCHANGED > if necessary (with testcase) The tests fail here: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so rebar.c && touch rebar.ok rebar.c:696: Test failed: (int)SendMessage(hRebar, RB_GETROWCOUNT, 0, 0) expected 2 got 1 rebar.c:696: Test failed: invalid rect (notify) (-1,-1) (-1,-1) - expected (0,0) (672,20) make: *** [rebar.ok] Error 2 -- Alexandre Julliard [EMAIL PROTECTED]
Re: dlls: Move the 16-bit dll stubs to the appropriate subdirectories.
Brian Gerst <[EMAIL PROTECTED]> writes: >>From 36873109949f308cc9d34f4df9bb0af4c219262b Mon Sep 17 00:00:00 2001 > From: Brian Gerst <[EMAIL PROTECTED]> > Date: Sat, 24 Feb 2007 08:59:48 -0500 > Subject: dlls: Move the 16-bit dll stubs to the appropriate subdirectories. This won't work, they won't be found when running inside the build tree. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine and msys rxvt.exe
On Sunday 25 February 2007 22:30, L. Rahyen wrote: > Sunday February 25 2007 07:52、Wesley Parish さんは書きました: > > I installed msys a couple of years back, and decided to test rxvt.exe: > > > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > > libGL warning: 3D driver claims to not support visual 0x4b > > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially > > implemented fixme:advapi:LsaOpenPolicy > > ((null),0x68f478,0x0001,0x68f494) stub fixme:advapi:LsaClose (0xcafe) > > stub > > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 > > 0x68ef0c 8 L"DOMAIN" (nil)) > > fixme:advapi:LsaClose (0xcafe) stub > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > failed to load libX11.dllbash-3.1$ > > > > bash-3.1$ wine --version > > wine-0.9.29 > > > > Those are the error messages. > > > > My version of wine is a little old. Have the fixme's been fixed in the > > latest wine? > > Fixmes doesn't mean problems if there is no problems. This is rule of > thumb. If you want to get help please tell what problems you see when > trying to run the software. And if you can give a link to download demo > version of the software (or full version if it's free). Can do, will do. http://www.mingw.org/msys.shtml http://sourceforge.net/project/showfiles.php?group_id=2435 It's free. -- Clinersterton beademung, with all of love - RIP James Blish - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.
Re: wine and msys rxvt.exe
That is the case. cygwin's just one of several POSIX environments on the Win32 platform, and msys is the other FOSS POSIX environment on Win32. I thought it would be a good test. I will have to upgrade my Wine version, admittedly ... Wesley Parish On Monday 26 February 2007 18:59, John Smith wrote: > If I recall correctly, MSYS is the mingw linux environment emulated on > windows. rxvt would be the terminal used in the msys environment. > > Hopefully this will be of some use, > John Klehm > > On 2/25/07, Robert Shearman <[EMAIL PROTECTED]> wrote: > > Wesley Parish wrote: > > > I installed msys a couple of years back, and decided to test rxvt.exe: > > > > > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > > > libGL warning: 3D driver claims to not support visual 0x4b > > > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially > > > > implemented > > > > > fixme:advapi:LsaOpenPolicy ((null),0x68f478,0x0001,0x68f494) stub > > > fixme:advapi:LsaClose (0xcafe) stub > > > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > > > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 > > > > 0x68ef0c 8 > > > > > L"DOMAIN" (nil)) > > > fixme:advapi:LsaClose (0xcafe) stub > > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > > failed to load libX11.dllbash-3.1$ > > > > > > bash-3.1$ wine --version > > > wine-0.9.29 > > > > > > Those are the error messages. > > > > > > My version of wine is a little old. Have the fixme's been fixed in the > > > > latest > > > > > wine? > > > > What is the program supposed to do? > > > > -- > > Rob Shearman -- Clinersterton beademung, with all of love - RIP James Blish - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.
