Wine Test Shell - timeouts during test runs too short?
Hi, When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places. These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow. The others (such as kernel32:debugger) may be the same - especially when you get mixed results from different runs. Because of this, the timeout length should be increased (I would say at least doubled, to allow the long-running tests to run through). Another thing... I find it breaks the idea of an automated test run to have to watch it to OK the timeout messages. I know that UAC and the shfileop tests bring up interactive dialogs, but these are from within Windows itself, and will be dealt with by the timeout/test killer part of the Wine Test Shell. This would help make it easier for people to run the tests more often. - Reece
Re: Wine Test Shell - timeouts during test runs too short?
Am Sonntag, 27. Januar 2008 13:49:36 schrieb Reece Dunn: On 27/01/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn: Hi, When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places. These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow. If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and visual tests will attempt to use the RGB software rendering device, which *is* slow. Running the visual test takes a few minutes instead of a few secounds. These are running on a decent spec Vista machine that is not running through VM. I don't know if 3D acceleration is on; it looks like it is off (the colour gradiant sweep tests take a while to flick through). This is strange though, because it is the default configuration for the Vista machine and games like Oblivion and Command and Conquer 3 play fine (but those are using D3D, not DDraw). The ddraw d3d and visual tests use d3d - earliear d3d versions(d3d = 7) are a subset of ddraw.dll . It could be that your driver doesn't like something about the way the test initializes d3d, so the test falls back to the software renderer.
Re: d3dx8: Implement D3DXCreateTextureFromFile
On Sunday 27 January 2008 12:39:18 am Luis C. Busquets Pérez wrote:
+{
+ FIXME((void): stub\n);
+ return D3D_OK;
+}
You probably shouldn't return okay if you're not implementing the function.
It's normal to return D3DERR_NOTIMPLEMENTED (or whatever it is). At the very
least you don't want to leave the output parameters untouched.
Re: Wine Test Shell - timeouts during test runs too short?
Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn: Hi, When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places. These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow. If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and visual tests will attempt to use the RGB software rendering device, which *is* slow. Running the visual test takes a few minutes instead of a few secounds. I've considered using the Reference rasterizer, which is even slower, as a fallback for the d3d9 tests, however, running the d3d9 visual tests in the refrast in qemu takes approximately 5 hours, so I dropped the idea. Furthermore the d3d9 refrast has to be installed separately.
Re: Wine Test Shell - timeouts during test runs too short?
On 27/01/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn: Hi, When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places. These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow. If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and visual tests will attempt to use the RGB software rendering device, which *is* slow. Running the visual test takes a few minutes instead of a few secounds. These are running on a decent spec Vista machine that is not running through VM. I don't know if 3D acceleration is on; it looks like it is off (the colour gradiant sweep tests take a while to flick through). This is strange though, because it is the default configuration for the Vista machine and games like Oblivion and Command and Conquer 3 play fine (but those are using D3D, not DDraw). Do you know how to turn 3D acceleration on in Vista? That said, Wine Test Shell should accept this as a valid test run and not timeout. - Reece
RegOverridePredefKey stub
Hello all,
I'm a Windows software developer and I'm trying to execute an application
under the wine environment.
Now I have a problem introduced with wine 0.9.49.
I use the function RegOverridePredefKey from the advapi32.dll.
In wine 0.9.49 a stub entry for this function was created, but the
implementation is missing.
To hold my code running, I need any implememtation for this function.
Please apply the attached patch for a stub implementation.
Thank you
Jens
diff -urN wine-0.9.52/dlls/advapi32/advapi32.spec wine-0.9.52_new/dlls/advapi32/advapi32.spec
--- wine-0.9.52/dlls/advapi32/advapi32.spec 2007-12-28 16:26:23.0 +0100
+++ wine-0.9.52_new/dlls/advapi32/advapi32.spec 2008-01-04 21:35:05.0 +0100
@@ -499,7 +499,7 @@
@ stdcall RegOpenKeyExW(long wstr long long ptr)
@ stdcall RegOpenKeyW(long wstr ptr)
@ stdcall RegOpenUserClassesRoot(ptr long long ptr)
-@ stub RegOverridePredefKey
+@ stdcall RegOverridePredefKey(long long)
@ stdcall RegQueryInfoKeyA(long ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr)
@ stdcall RegQueryInfoKeyW(long ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr)
@ stdcall RegQueryMultipleValuesA(long ptr long ptr ptr)
diff -urN wine-0.9.52/dlls/advapi32/registry.c wine-0.9.52_new/dlls/advapi32/registry.c
--- wine-0.9.52/dlls/advapi32/registry.c 2007-12-28 16:26:23.0 +0100
+++ wine-0.9.52_new/dlls/advapi32/registry.c 2008-01-04 21:34:59.0 +0100
@@ -2407,6 +2407,45 @@
}
/**
+ * RegOverridePredefKey [EMAIL PROTECTED]
+ *
+ * Maps a predefined registry key to the specified registry key.
+ *
+ * PARAMS
+ * hKey [I] A handle to one of the following predefined keys:
+ * HKEY_CLASSES_ROOT
+ * HKEY_CURRENT_CONFIG
+ * HKEY_CURRENT_USER
+ * HKEY_LOCAL_MACHINE
+ * HKEY_PERFORMANCE_DATA
+ * HKEY_USERS
+ * hNewHKey [I] A handle to an open registry key. This handle is returned by the RegCreateKeyEx or RegOpenKeyEx function.
+ * It cannot be one of the predefined keys. The function maps hKey to refer to the hNewHKey key.
+ * This affects only the calling process.
+ * If hNewHKey is NULL, the function restores the default mapping of the predefined key.
+ *
+ * RETURNS
+ * Success: ERROR_SUCCESS
+ * Failure: the return value is a nonzero error code defined in Winerror.h
+ *
+ * NOTES
+ * The RegOverridePredefKey function is intended for software installation programs.
+ * It allows them to remap a predefined key, load a DLL component that will be installed on the system,
+ * call an entry point in the DLL, and examine the changes to the registry that the component attempted to make.
+ * The installation program can then write those changes to the locations intended by the DLL,
+ * or make changes to the data before writing it.
+ *
+ * FIXME
+ * function must be implemented
+ */
+
+LSTATUS WINAPI RegOverridePredefKey(HKEY hKey, HKEY hNewHKey)
+ {
+ FIXME((%p, %p) stub\n, hKey, hNewHKey);
+ return ERROR_CALL_NOT_IMPLEMENTED;
+ }
+
+/**
* load_string [Internal]
*
* This is basically a copy of user32/resource.c's LoadStringW. Necessary to
Re: RegOverridePredefKey stub
On So, 2008-01-27 at 14:35 +0100, Jens Nestler wrote: Please apply the attached patch for a stub implementation. Please send patches to [EMAIL PROTECTED] Thanks. -- By by ... Detlef
[Fwd: d3dx8: Implement D3DXCreateTextureFromFile]
I have created a /dlls/d3dx8/texture.c file where to put all functions
related to textures and d3dx8.
I have included D3DXIMAGE_FILEFORMAT in the patch because it is referred
by D3DXIMAGE_FILEFORMAT which is referred in the function. If not
included, it would not compile. They both are now in /include/d3dx8.h
whci I think is the appropiate file. Do you propose to put them elsewhere?
Do you think I am missing anything or is it ok?
---BeginMessage---
Implementation of the simple D3DXCreateTextureFromFile functions in
relation to the Extended functions
---
dlls/d3dx8/Makefile.in |1 +
dlls/d3dx8/d3dx8.spec |8 ++--
dlls/d3dx8/texture.c | 86
include/d3dx8.h|1 +
include/d3dx8texture.h | 43
5 files changed, 135 insertions(+), 4 deletions(-)
create mode 100644 dlls/d3dx8/texture.c
create mode 100644 include/d3dx8texture.h
diff --git a/dlls/d3dx8/Makefile.in b/dlls/d3dx8/Makefile.in
index cbee6e5..d56807e 100644
--- a/dlls/d3dx8/Makefile.in
+++ b/dlls/d3dx8/Makefile.in
@@ -10,6 +10,7 @@ EXTRALIBS = -ldxguid -luuid
C_SRCS = \
d3dx8_main.c \
d3dxbuffer.c \
+ texture.c \
math.c
@MAKE_DLL_RULES@
diff --git a/dlls/d3dx8/d3dx8.spec b/dlls/d3dx8/d3dx8.spec
index 0ccfdf2..929fe0a 100644
--- a/dlls/d3dx8/d3dx8.spec
+++ b/dlls/d3dx8/d3dx8.spec
@@ -129,12 +129,12 @@
@ stub D3DXLoadVolumeFromMemory
@ stub D3DXCheckTextureRequirements
@ stub D3DXCreateTexture
-@ stub D3DXCreateTextureFromFileA
-@ stub D3DXCreateTextureFromFileW
+@ stdcall D3DXCreateTextureFromFileA(ptr ptr ptr)
+@ stdcall D3DXCreateTextureFromFileW(ptr ptr ptr)
@ stub D3DXCreateTextureFromResourceA
@ stub D3DXCreateTextureFromResourceW
-@ stub D3DXCreateTextureFromFileExA
-@ stub D3DXCreateTextureFromFileExW
+@ stdcall D3DXCreateTextureFromFileExA(ptr ptr long long long long ptr ptr long long ptr ptr ptr ptr)
+@ stdcall D3DXCreateTextureFromFileExW(ptr ptr long long long long ptr ptr long long ptr ptr ptr ptr)
@ stub D3DXCreateTextureFromResourceExA
@ stub D3DXCreateTextureFromResourceExW
@ stub D3DXCreateTextureFromFileInMemory
diff --git a/dlls/d3dx8/texture.c b/dlls/d3dx8/texture.c
new file mode 100644
index 000..fd98f76
--- /dev/null
+++ b/dlls/d3dx8/texture.c
@@ -0,0 +1,86 @@
+/*
+ * Direct3D X 8 texture file
+ *
+ * Copyright (C) 2008 Luis C. Busquets Pérez
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ *
+ */
+
+#include config.h
+#include wine/port.h
+#include stdarg.h
+#include windef.h
+#include winbase.h
+#include wingdi.h
+#include winuser.h
+#include wine/debug.h
+#include d3dx8_private.h
+
+WINE_DEFAULT_DEBUG_CHANNEL(d3d);
+
+HRESULT WINAPI D3DXCreateTextureFromFileExW(LPDIRECT3DDEVICE8 pDevice,
+LPWSTR pSrcFile,
+UINT Width,
+UINT Height,
+UINT MipLevels,
+DWORD Usage,
+D3DFORMAT Format,
+D3DPOOL Pool,
+DWORD Filter,
+DWORD MipFilter,
+D3DCOLOR ColorKey,
+D3DXIMAGE_INFO *pSrcInfo,
+PALETTEENTRY *pPalette,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ FIXME((void): stub\n);
+ return D3D_OK;
+}
+
+HRESULT WINAPI D3DXCreateTextureFromFileW(LPDIRECT3DDEVICE8 pDevice,
+LPWSTR pSrcFile,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ return D3DXCreateTextureFromFileExW(pDevice, pSrcFile, 0, 0, 0, 0, 1, 0, 0, 0, 0, NULL,NULL, ppTexture);
+}
+
+HRESULT WINAPI D3DXCreateTextureFromFileExA(LPDIRECT3DDEVICE8 pDevice,
+LPSTR pSrcFile,
+UINT Width,
+UINT Height,
+UINT MipLevels,
+DWORD Usage,
+D3DFORMAT Format,
+D3DPOOL Pool,
+DWORD Filter,
+DWORD MipFilter,
+D3DCOLOR ColorKey,
+D3DXIMAGE_INFO *pSrcInfo,
+PALETTEENTRY *pPalette,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ FIXME((void): stub\n);
+ return D3D_OK;
+}
+
+HRESULT WINAPI D3DXCreateTextureFromFileA(LPDIRECT3DDEVICE8 pDevice,
+LPSTR pSrcFile,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ return D3DXCreateTextureFromFileExA(pDevice, pSrcFile, 0, 0, 0, 0, 1, 0, 0, 0, 0, NULL,NULL, ppTexture);
+}
+
+
diff --git a/include/d3dx8.h b/include/d3dx8.h
index 52ddaf3..e446a56 100644
--- a/include/d3dx8.h
+++ b/include/d3dx8.h
@@ -24,5 +24,6 @@
#include d3dx8math.h
d3dx: A few last questions...
Hi, So far I have pretty much completed the d3dx9_24 dll. However, while writing the spec files I faced a few problems which I'd like to have solved befor submitting the patch: 1. With the d3dx9_31 dll, microsoft removed three functions from the SDK. I'm curious what to do with them. Should I stub them at the first or last dll they're used in? Also, How should I handle the forwarding thing then? I'm importing d3dx9_36 in each dll, but need to import the dll containing the three functions, too (I'm just asking to make sure there won't be any collisions or conflicts or something). By the way, the three functions are D3DXCpuOptimizations, GetTargetDescByName and GetTargetDescByVersion. 2. Another problem is, that many functions changed in there argument list from one version to the next one. For example http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_Summer_04/directx/graphics/d3dxapichanges.asp Says, that D3DXCreateFont changed the type of the D3DXFONT_DESC member Height from UINT to INT. I think (but don't know, so I ask) that this could lead to a misbehavior in some programs, as a UINT has a significant difference in the bit structure to INT. Also, the Angle parameter in D3DXSHRotateZ was changed from const FLOAT to FLOAT, which COULD also lead to problems. 3. Also, the MSDN seems to lack the info about D3DXGetTargetDescByName and D3DXGetTargetDescByVersion. I'd be really gradeful if someone who has an old version of the DXSDK installed could take a look into the headers and tell me the argument list. 4. And just to make sure, I attached the d3dx9_24 specfile. Everything but the argument types should be okay I think, but please tell me if you find any other problems with it, like typos in function names or something about the forwarding. Also, the two D3DXGetTargetDescByName/Version functions don't have argument lists yet as I couldn't find resources about them. That's it at the moment, I'll reply later to this topic if there appear new problems. Thanks for any answers, best regards Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html d3dx9_24.spec Description: Binary data
RE : [Fwd: d3dx8: Implement D3DXCreateTextureFromFile]
The real file is d3dx8tex.h and not d3dx8texture.h. You need to use the same name as windows uses. David Luis C. Busquets Pérez [EMAIL PROTECTED] a écrit : I have created a /dlls/d3dx8/texture.c file where to put all functions related to textures and d3dx8. I have included D3DXIMAGE_FILEFORMAT in the patch because it is referred by D3DXIMAGE_FILEFORMAT which is referred in the function. If not included, it would not compile. They both are now in /include/d3dx8.h whci I think is the appropiate file. Do you propose to put them elsewhere? Do you think I am missing anything or is it ok? - Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
Re: Wiki Down?
Dimi Paun wrote: On Fri, 2008-01-25 at 15:06 -0600, Austin English wrote: What happened to the wiki? AppDB/WineHQ/Bugzilla are all fine, but wiki.winehq.org seems to be down. The wiki is up. In fact, it was always up, but there was a little problem with the DNS yesterday (I think from 1-8PM EST) that affected our environment. It's been fixed, sorry for the downtime. Thank you for fixing the DNS problem. James McKenzie
d3dx8: Implement D3DXCreateTextureFromFile functions in relation to the extended version - 3rd try
d3dx8tex.h with the mentioned name.
I should be done now. Please send comments if not.
---
dlls/d3dx8/Makefile.in |1 +
dlls/d3dx8/d3dx8.spec |8 ++--
dlls/d3dx8/texture.c | 86
include/d3dx8.h|1 +
include/d3dx8tex.h | 43
5 files changed, 135 insertions(+), 4 deletions(-)
create mode 100644 dlls/d3dx8/texture.c
create mode 100644 include/d3dx8tex.h
diff --git a/dlls/d3dx8/Makefile.in b/dlls/d3dx8/Makefile.in
index cbee6e5..d56807e 100644
--- a/dlls/d3dx8/Makefile.in
+++ b/dlls/d3dx8/Makefile.in
@@ -10,6 +10,7 @@ EXTRALIBS = -ldxguid -luuid
C_SRCS = \
d3dx8_main.c \
d3dxbuffer.c \
+ texture.c \
math.c
@MAKE_DLL_RULES@
diff --git a/dlls/d3dx8/d3dx8.spec b/dlls/d3dx8/d3dx8.spec
index 0ccfdf2..929fe0a 100644
--- a/dlls/d3dx8/d3dx8.spec
+++ b/dlls/d3dx8/d3dx8.spec
@@ -129,12 +129,12 @@
@ stub D3DXLoadVolumeFromMemory
@ stub D3DXCheckTextureRequirements
@ stub D3DXCreateTexture
-@ stub D3DXCreateTextureFromFileA
-@ stub D3DXCreateTextureFromFileW
+@ stdcall D3DXCreateTextureFromFileA(ptr ptr ptr)
+@ stdcall D3DXCreateTextureFromFileW(ptr ptr ptr)
@ stub D3DXCreateTextureFromResourceA
@ stub D3DXCreateTextureFromResourceW
-@ stub D3DXCreateTextureFromFileExA
-@ stub D3DXCreateTextureFromFileExW
+@ stdcall D3DXCreateTextureFromFileExA(ptr ptr long long long long ptr ptr long long ptr ptr ptr ptr)
+@ stdcall D3DXCreateTextureFromFileExW(ptr ptr long long long long ptr ptr long long ptr ptr ptr ptr)
@ stub D3DXCreateTextureFromResourceExA
@ stub D3DXCreateTextureFromResourceExW
@ stub D3DXCreateTextureFromFileInMemory
diff --git a/dlls/d3dx8/texture.c b/dlls/d3dx8/texture.c
new file mode 100644
index 000..fd98f76
--- /dev/null
+++ b/dlls/d3dx8/texture.c
@@ -0,0 +1,86 @@
+/*
+ * Direct3D X 8 texture file
+ *
+ * Copyright (C) 2008 Luis C. Busquets Pérez
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ *
+ */
+
+#include config.h
+#include wine/port.h
+#include stdarg.h
+#include windef.h
+#include winbase.h
+#include wingdi.h
+#include winuser.h
+#include wine/debug.h
+#include d3dx8_private.h
+
+WINE_DEFAULT_DEBUG_CHANNEL(d3d);
+
+HRESULT WINAPI D3DXCreateTextureFromFileExW(LPDIRECT3DDEVICE8 pDevice,
+LPWSTR pSrcFile,
+UINT Width,
+UINT Height,
+UINT MipLevels,
+DWORD Usage,
+D3DFORMAT Format,
+D3DPOOL Pool,
+DWORD Filter,
+DWORD MipFilter,
+D3DCOLOR ColorKey,
+D3DXIMAGE_INFO *pSrcInfo,
+PALETTEENTRY *pPalette,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ FIXME((void): stub\n);
+ return D3D_OK;
+}
+
+HRESULT WINAPI D3DXCreateTextureFromFileW(LPDIRECT3DDEVICE8 pDevice,
+LPWSTR pSrcFile,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ return D3DXCreateTextureFromFileExW(pDevice, pSrcFile, 0, 0, 0, 0, 1, 0, 0, 0, 0, NULL,NULL, ppTexture);
+}
+
+HRESULT WINAPI D3DXCreateTextureFromFileExA(LPDIRECT3DDEVICE8 pDevice,
+LPSTR pSrcFile,
+UINT Width,
+UINT Height,
+UINT MipLevels,
+DWORD Usage,
+D3DFORMAT Format,
+D3DPOOL Pool,
+DWORD Filter,
+DWORD MipFilter,
+D3DCOLOR ColorKey,
+D3DXIMAGE_INFO *pSrcInfo,
+PALETTEENTRY *pPalette,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ FIXME((void): stub\n);
+ return D3D_OK;
+}
+
+HRESULT WINAPI D3DXCreateTextureFromFileA(LPDIRECT3DDEVICE8 pDevice,
+LPSTR pSrcFile,
+LPDIRECT3DTEXTURE8 *ppTexture)
+{
+ return D3DXCreateTextureFromFileExA(pDevice, pSrcFile, 0, 0, 0, 0, 1, 0, 0, 0, 0, NULL,NULL, ppTexture);
+}
+
+
diff --git a/include/d3dx8.h b/include/d3dx8.h
index 52ddaf3..fefba46 100644
--- a/include/d3dx8.h
+++ b/include/d3dx8.h
@@ -24,5 +24,6 @@
#include d3dx8math.h
#include d3dx8core.h
+#include d3dx8tex.h
#endif
diff --git a/include/d3dx8tex.h b/include/d3dx8tex.h
new file mode 100644
index 000..3167edf
--- /dev/null
+++ b/include/d3dx8tex.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008 Luis C. Busquets Pérez
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the
Re: Vacation
On Jan 27, 2008 8:50 AM, Detlef Riekenberg [EMAIL PROTECTED] wrote: On Sa, 2008-01-26 at 10:17 +0100, Alexandre Julliard wrote: I'm off skiing for a week... Which area? (I'm a bit of a skiing nut :-) --John
Re: start.exe: Handle the process title argument
Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote:
+ NOTE: This will only work when run from Wine's cmd, but that's ok
as start is a builtin
+ shell command on NT */
What's the purpose of the comment above?
+if(argc 1 (vi.dwMajorVersion = 5 || (vi.dwMajorVersion == 4
vi.dwPlatformId == 2)))
Unless there is an app which would break because of the title set there is no
need to check the version.
+{
+int cmdcount;
+WCHAR* cmdline = GetCommandLineW();
+WCHAR** cmdargs = CommandLineToArgvW(cmdline, cmdcount);
+WCHAR* pos = cmdline;
wmain() already has arc/argv pair of parameters, why do you need to parse
command line again?
+
+pos += lstrlenW(cmdargs[0]);
+
+while(*pos == ' ')
+pos++;
+
+if(*pos == '')
+{
+/* FIXME: Set the process title */
+i++;
+}
+LocalFree(cmdargs);
+}
I assume that you've added LocalFree as MSDN suggests, but CommandLineToArgvW
in Wine uses GlobalAlloc, perhaps you could fix that?
--
Dmitry.
