November 2005 - Wine-Devel - list.winehq.org

Spelling error?
by Saulius Krasuckas Nov. 21, 2005

Nov. 21, 2005

This one comes from old Erics patch, and I may be wrong with a french language here, but wouldn't one name be spelled differently here? :-] Index: dlls/kernel/tests/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/process.c,v retrieving revision 1.23 diff -p -u -r1.23 process.c --- dlls/kernel/tests/process.c 27 Oct 2005 10:25:49 -0000 1.23 +++ dlls/kernel/tests/process.c 21 Nov 2005 10:39:35 -0000 @@ -724,7 +725,7 @@ static void test_CommandLine(void) startup.dwFlags = STARTF_USESHOWWINDOW; startup.wShowWindow = SW_SHOWNORMAL; - /* from Frangois */ + /* from Francois */ get_file_name(resfile); sprintf(buffer, "%s tests/process.c %s \"a\\\"b\\\\\" c\\\" d", selfname, resfile); ok(CreateProcessA(NULL, buffer, NULL, NULL, FALSE, 0L, NULL, NULL, &startup, &info), "CreateProcess\n");

2 1

DirectX 8 wrapper update
by Oliver Stieber Nov. 21, 2005

Nov. 21, 2005

Hi, I've updated the directX 8 wrapper with a load more bug fixes notably Max payne 2 now works correctly. For anyone who's interested the update patch is avaialble here: https://sourceforge.net/project/shownotes.php?release_id=371929&group_id=13… Thanks, Oliver ___________________________________________________________ Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/

5 13

Re: [wined3d] pixel shader cross compiler [2] resend
by Alexandre Julliard Nov. 21, 2005

Nov. 21, 2005

Oliver Stieber <oliver_stieber(a)yahoo.co.uk> writes: > const IWineD3DPixelShaderVtbl IWineD3DPixelShader_Vtbl = > { > @@ -118,5 +1824,7 @@ > /*** IWineD3DPixelShader methods ***/ > IWineD3DPixelShaderImpl_GetParent, > IWineD3DPixelShaderImpl_GetDevice, > - IWineD3DPixelShaderImpl_GetFunction > + IWineD3DPixelShaderImpl_GetFunction, > + /* not part of d3d */ > + IWineD3DPixelShaderImpl_SetFunction There are missing entries before SetFunction. -- Alexandre Julliard julliard(a)winehq.org

1 0

Another Multithreaded Direct3D biest??
by Stefan Dösinger Nov. 21, 2005

Nov. 21, 2005

Hello, After quite some time I returned to my D3D7->WineD3D work, and I gave Need for speed 3 a try. It's an old DirectX 5 game, with DirectDraw software rendering, Direct3D rendering and some hardware specific renderers. Need for speed 3 causes a crash in the GL library. A look at a +tid,+ddraw, +d3d trace shows that it creates a DirectDraw object in TID 0x9(No D3D involved), and then switches the graphics operations to another thread, 0xc. This thread sucessfully created and releases 2 DirectDraw and Direct3D objects. When the third WineD3D object is created, a crash in glXMakeCurrent in swapchain.c::IWineD3DDeviceImpl_CreateAdditionalSwapChain occurs. Is this a multithread problem? There's one thread change involved, but it occurs before the first Direct3D object is created. Does anyone know any not multithreaded Direct3D7(or previous) games, which do not rely on ProcessVertices?? Which games are working with the old D3D7 implementation? I have tried Empire Earth(Mulitthreaded), Half-Life 1 (ProcessVertices) and Need for Speed 3(Multithreaded??) now. Now I am running out of games :( Stefan

3 3

Fwd: MBR was destroyed
by seorge Nov. 21, 2005

Nov. 21, 2005

Hi, Since I'm not a developerr and therefore can't take part in any discussion here may I ask you to discuss the bug I reported, because Dustin Navea asked me to join this list. Or if nobody really need my presence here, please let me know and I will unsubscribe. Thanks in advance! ---------- Forwarded Message ---------- Subject: MBR was destroyed Date: Sunday 20 November 2005 08:49 From: seorge <seorge(a)gmail.com> To: wine-devel(a)winehq.org I've just submitted a bug (3889) about destroyed MBR and Dustin Navea asked me to subscribe to this list. Here comes some detailed description: As a regular user I've launched winecfg as a regular user, then proceeded to the dist setup. I've tried several options like automatic configuration, manual configuration. Then I've tried to change some drive letters manually. After reboot a "PRESS A KEY TO REBOOT" message appeared instead of a GRUB screen. Next time I booted with grub-floppy and then restored the MBR with grub-install /dev/hda. Please let me know what additional information you need. It's happend on Slackware 10.2 system, 2.6.14 kernel with ck-3 patches. -------------------------------------------------------

4 3

Re: [advpack/setupapi] LaunchINFSection
by Robert Shearman Nov. 21, 2005

Nov. 21, 2005

Raphael wrote: > Changelog: > - semi implementation of advpack APIs LaunchINFSection/LaunchINFSectionEx > - semi implementation of advpack API ExtractFiles > - setupapi: correct and check pExtractFiles return code > > I have a few comments: >------------------------------------------------------------------------ >@@ -91,30 +105,132 @@ > } > > /*********************************************************************** >- * LaunchINFSection (ADVPACK.@) >- */ >-void WINAPI LaunchINFSection( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) >-{ >- FIXME("(%p %p %s %d): stub\n", hWnd, hInst, debugstr_a(cmdline), show ); >-} >- >-/*********************************************************************** > * LaunchINFSectionEx (ADVPACK.@) > */ >-void WINAPI LaunchINFSectionEx( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) >+static UINT LaunchINFSectionEx_CabExtractCallBackA(PVOID Context, UINT Notification, UINT_PTR Param1, UINT_PTR Param2) > { >- FIXME("(%p %p %s %d): stub\n", hWnd, hInst, debugstr_a(cmdline), show ); >-} >+ LPCSTR file = (LPCSTR) Context; >+ PFILE_IN_CABINET_INFO_A pInfo = (PFILE_IN_CABINET_INFO_A) Param1; >+ if ( Notification != SPFILENOTIFY_FILEINCABINET ) return 0; >+ assert( 0 != Param1 ); > > Why bother with the assert? You'll crash more nicely by just dereferencing the NULL pointer. At least then you'll get a backtrace in the debugger. >+ if (0 != strcmp(file, pInfo->NameInCabinet)) return FILEOP_SKIP; >+ lstrcpyA(pInfo->FullTargetName, pInfo->NameInCabinet); >+ TRACE("Extraction of '%s'\n", pInfo->NameInCabinet); >+ return FILEOP_DOIT; >+} >+ >+HRESULT WINAPI LaunchINFSectionEx( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) >+{ >+ CHAR inf_name[512]; >+ CHAR section_name[512]; >+ CHAR cab_name[512]; >+ CHAR szFlags[48]; >+ CHAR szShow[2]; >+ DWORD dwFlags; >+ CHAR* cursor = NULL; >+ SIZE_T sz = 0; >+ BOOL bTest; >+ HINF hinf; >+ void* callback_context; > >-/* this structure very closely resembles parameters of RunSetupCommand() */ >-typedef struct >-{ >- HWND hwnd; >- LPCSTR title; >- LPCSTR inf_name; >- LPCSTR dir; >- LPCSTR section_name; >-} SETUPCOMMAND_PARAMS; >+ FIXME("(%p %p %s %d): semi-stub\n", hWnd, hInst, debugstr_a(cmdline), show ); >+ >+ cursor = strchr(cmdline, ','); >+ if (NULL == cursor) { return E_INVALIDARG; } > > This is just personal preference, but the extra brackets there aren't needed and don't add to the readability and I haven't seen this style used elsewhere in the Wine source code. >+ sz = (cursor - cmdline) + 1; >+ lstrcpynA(inf_name, cmdline, sz); inf_name[sz] = 0; >+ cmdline = cursor + 1; >+ >+ cursor = strchr(cmdline, ','); >+ if (NULL == cursor) { return E_INVALIDARG; } >+ sz = (cursor - cmdline) + 1; >+ lstrcpynA(section_name, cmdline, sz); section_name[sz] = 0; >+ cmdline = cursor + 1; >+ >+ cursor = strchr(cmdline, ','); >+ if (NULL == cursor) { return E_INVALIDARG; } >+ sz = (cursor - cmdline) + 1; >+ lstrcpynA(cab_name, cmdline, sz); cab_name[sz] = 0; >+ cmdline = cursor + 1; >+ >+ cursor = strchr(cmdline, ','); >+ if (NULL == cursor) { return E_INVALIDARG; } >+ sz = (cursor - cmdline) + 1; >+ lstrcpynA(szFlags, cmdline, sz); szFlags[sz] = 0; >+ cmdline = cursor + 1; >+ >+ lstrcpynA(szShow, cmdline, 2); szShow[1] = 0; >+ >+ dwFlags = atol(szFlags); >+ >+ TRACE("cab name('%s')\n", cab_name); >+ TRACE("inf name('%s')\n", inf_name); >+ TRACE("inf section name('%s')\n", section_name); >+ TRACE("flags('%s','%lu')\n", szFlags, dwFlags); >+ TRACE("nShow('%s')\n", szShow); >+ >+ if (dwFlags & 0x04) { >+ FIXME("dwFlags: Quiet Mode\n"); >+ } >+ if (dwFlags & 0x08) { >+ FIXME("dwFlags: Don't Run GrpConv\n"); >+ FIXME("Unsupported\n"); return E_NOTIMPL; >+ } >+ if (dwFlags & 16) { >+ FIXME("dwFlags: Force self-updating\n"); >+ FIXME("Unsupported\n"); return E_NOTIMPL; >+ } >+ if (dwFlags & 32) { >+ FIXME("dwFlags: Backup data before install\n"); >+ } >+ if (dwFlags & 64) { >+ FIXME("dwFlags: Rollback data to previous state\n"); >+ /*FIXME("Unsupported\n"); return E_NOTIMPL;*/ >+ } >+ if (dwFlags & 128) { >+ FIXME("dwFlags: Validate Backup data before install\n"); >+ FIXME("Unsupported\n"); return E_NOTIMPL; >+ } >+ if (dwFlags & 256) { >+ FIXME("dwFlags: Rollback data to previous state\n"); >+ FIXME("Unsupported\n"); return E_NOTIMPL; >+ } >+ if (dwFlags & 512) { >+ FIXME("dwFlags: Force delay of OCX registration\n"); >+ FIXME("Unsupported\n"); return E_NOTIMPL; >+ } >+ >+ if (0 != strcmp(cab_name, "")) { >+ FIXME("Unsupported Cab Extraction\n"); return E_NOTIMPL; > > Is this left over debugging code? >+ bTest = SetupIterateCabinetA(cab_name, 0, >+ (PSP_FILE_CALLBACK_A) LaunchINFSectionEx_CabExtractCallBackA, >+ (LPVOID) inf_name); > > Don't cast LaunchINFSectionEx_CabExtractCallBackA. That's a recipe for using a function with an incorrect calling convention and trashing the stack. >+ if (!bTest) return E_FAIL; > > Don't use E_FAIL. Try to return a proper error code, preferably using what native returns in this circumstance by adding a test case. >+ } >+ >+ hinf = SetupOpenInfFileA(inf_name, NULL, INF_STYLE_WIN4, NULL); >+ if (hinf == INVALID_HANDLE_VALUE) { >+ ERR("Failed to SetupOpenInfFileA(%s)\n", inf_name); >+ return E_FAIL; > > Again, don't use E_FAIL. Also consider adding some more debugging information to the error message (like, say, the value returned by GetLastError()). >+ } >+ >+ callback_context = SetupInitDefaultQueueCallback(hWnd); >+ bTest = SetupInstallFromInfSectionA(NULL, hinf, >+ section_name, >+ SPINST_ALL, >+ NULL, NULL, 0, >+ SetupDefaultQueueCallbackA, >+ callback_context, >+ NULL, NULL); >+ SetupTermDefaultQueueCallback(callback_context); >+ SetupCloseInfFile(hinf); >+ >+ if (!bTest) { >+ ERR("Failed to SetupInstallFromInfSectionA(%s, %s)\n", inf_name, section_name); >+ return E_FAIL; > > Again, don't use E_FAIL - return a proper error code. >+ } >+ return S_OK; >+} > > /*********************************************************************** > * DoInfInstall (ADVPACK.@) >@@ -144,6 +260,15 @@ > } > > /*********************************************************************** >+ * LaunchINFSection (ADVPACK.@) >+ */ >+HRESULT WINAPI LaunchINFSection( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) >+{ >+ FIXME("(%p %p %s %d): semi-stub\n", hWnd, hInst, debugstr_a(cmdline), show ); > > Can you give us a clue as to what the difference between LaunchINFSection and LaunchINFSectionEx might be by adding a comment? If you don't know, a comment would still be appreciated saying that it should be doing something different here. >+ return LaunchINFSectionEx( hWnd, hInst, cmdline, show ); >+} >+ >+/*********************************************************************** > * IsNTAdmin (ADVPACK.@) > */ > BOOL WINAPI IsNTAdmin( DWORD reserved, PDWORD pReserved ) >@@ -395,16 +520,59 @@ > /*********************************************************************** > * ExtractFiles (ADVPACK.@) > * >+ * @param CabName: Cabinet file path >+ * @param ExpandDir: Extraction Output Directory >+ * @param Flags: UNKNOWN >+ * @param FileList: if NULL extract all files >+ * else UNKNOWN >+ * > > I don't think that is a c2man compatible documentation format. > * BUGS > * Unimplemented > */ >+typedef struct >+{ >+ DWORD Flags; >+ LPCSTR ExpandDir; >+ LPCSTR FileList; >+} ExtractFiles_CabExtractCallBackA_params_t; >+ >+static UINT ExtractFiles_CabExtractCallBackA(PVOID Context, UINT Notification, UINT_PTR Param1, UINT_PTR Param2) >+{ >+ ExtractFiles_CabExtractCallBackA_params_t* pParams = (ExtractFiles_CabExtractCallBackA_params_t*) Context; >+ PFILE_IN_CABINET_INFO_A pInfo = (PFILE_IN_CABINET_INFO_A) Param1; >+ if ( Notification != SPFILENOTIFY_FILEINCABINET ) return 0; >+ assert( 0 != Param1 ); >+ assert( 0 != Param2 ); >+ /** stupid heuristic: waiting for better: ie. understanding what is FileList format */ >+ if (NULL != pParams->FileList) >+ { >+ if (NULL == strstr(pParams->FileList, pInfo->NameInCabinet)) return FILEOP_SKIP; >+ } >+ lstrcpyA(pInfo->FullTargetName, pParams->ExpandDir); >+ /** we should test if pParams->ExpandDir finished with "\" but each app examples i found have it */ >+ lstrcatA(pInfo->FullTargetName, pInfo->NameInCabinet); >+ TRACE("Extraction '%s' to '%s' (wanted Path was '%s')\n", pInfo->NameInCabinet, pInfo->FullTargetName, pParams->ExpandDir); >+ return FILEOP_DOIT; >+} > > HRESULT WINAPI ExtractFiles ( LPCSTR CabName, LPCSTR ExpandDir, DWORD Flags, > LPCSTR FileList, LPVOID LReserved, DWORD Reserved) > { >- FIXME("(%p %p 0x%08lx %p %p 0x%08lx): stub\n", CabName, ExpandDir, Flags, >+ ExtractFiles_CabExtractCallBackA_params_t params; >+ BOOL bTest; >+ >+ FIXME("(%p %p 0x%08lx %p %p 0x%08lx): semi-stub\n", CabName, ExpandDir, Flags, > FileList, LReserved, Reserved); >- return E_FAIL; >+ >+ params.Flags = Flags; >+ params.ExpandDir = ExpandDir; >+ params.FileList = FileList; >+ >+ bTest = SetupIterateCabinetA(CabName, 0, >+ (PSP_FILE_CALLBACK_A) ExtractFiles_CabExtractCallBackA, >+ (LPVOID) &params); > > Again, don't cast ExtractFiles_CabExtractCallBackA. Just fix up the declaration of that function if it issues a warning here. >+ if (!bTest) return E_FAIL; > > Again, don't use E_FAIL. -- Rob Shearman

2 2

Re: [advpack/setupapi] LaunchINFSection
by Dimi Paun Nov. 21, 2005

Nov. 21, 2005

On Wed, 2005-11-16 at 23:56 +0100, Raphael wrote: > + if (!bRet) { > + ERR("Failed to CopyFileW(%s, %s)\n", debugstr_w(src), > debugstr_w(dst)); > + } You shouldn't issue ERR if the function can deal with the error condition. Just return the appropriate error code. ERR is to signal a case that should NEVER happen. This is not the case in any of the instances where you used ERR in this patch. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Re: [advpack/setupapi] LaunchINFSection
by James Hawkins Nov. 21, 2005

Nov. 21, 2005

On 11/16/05, Raphael <fenix(a)club-internet.fr> wrote: > > Changelog: > - semi implementation of advpack APIs LaunchINFSection/LaunchINFSectionEx > - semi implementation of advpack API ExtractFiles > - setupapi: correct and check pExtractFiles return code > I appreciate your work on advpack, but some comments that might help get it accepted more easily: * separate the patch into as many independent chunks as you can. It seems like each function you implement can be sent in separate and linearly. * it would help to add test cases wherever you can even if it's just to check how the function handles parameters. > + if (!bRet) { > + ERR("Failed to CopyFileW(%s, %s)\n", debugstr_w(src), debugstr_w(dst)); > + } The rest of the file uses standard C indentation, so it's best to stick with that: if (x) { } but seeing as how it's just a one liner, if (!bRet) ERR("..."); -- James Hawkins

3 3

Re: D3D7 & WineD3D success
by Stefan Dösinger Nov. 20, 2005

Nov. 20, 2005

> Doesn't the demo for Tomb Raider 3 rely on wierdo installshield stuff? > I have the full version of that game (it came with my videocard) and I > can't get past the installer using the winehq wine tree. Not that I know... It installed without any problems here. The demo is a WinZip self extractor, which extracts an old (non-DCOM) installshield installer, which worked out of the box for me. But, for the game to run, you have to set the Windows Version to Win98, otherwise the game will stop with a privileged instruction exception during startup. Stefan

2 1

NTSTATUS values in ntstatus.h and winnt.h
by Ge van Geldorp Nov. 20, 2005

Nov. 20, 2005

The PSDK defines some NTSTATUS values in both ntstatus.h and in winnt.h, guarded by "#ifndef WIN32_NO_STATUS". Unfortunately, the definitions in the PSDK are not equivalent. In ntstatus.h: #define STATUS_xxx ((NTSTATUS) 0x........) In winnt.h: #define STATUS_xxx ((DWORD) 0x........) The Wine headers don't cast the literal to NTSTATUS resp DWORD. This means it is ok to #include both winnt.h and ntstatus.h without #defining WIN32_NO_STATUS using the Wine headers, but it is not ok to do so using PSDK (or, in my case, ReactOS) headers. Would a patch adding the appropriate casts in ntstatus.h/winnt.h and then fixing the resulting problems in Wine by #defining WIN32_NO_STATUS where appropriate (an example is dlls/netapi32/wksta.c) be acceptable? Gé van Geldorp.

1 0