wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

windows.h
by Steven Edwards 22 Nov '05

22 Nov '05

Hi All, I don't understand the reason we are still manually including each header in most of the sources. Its like totally incompatible with the latest PSDK unless you add a define for _X86_. We are getting to the point in some of the sources where we might as well just include Windows.h becuase we already include all of the files it includes or close enough to them. Can someone explain the reason to me we are still manually messing with a lot of these headers? Thanks Steven P.S. I have even read threads online where Microsoft's Visual Studio developers tell the users NOT to manually include WinNT, WinBase, etc.

2 1

Licensing and technical issues with a Wine package that includes the Mozilla ActiveX Control
by Scott Ritchie 22 Nov '05

22 Nov '05

Greetings, As part of my work to create the ultimate works-out-of-the-box Wine package, I've begun to ponder the idea of including the Mozilla ActiveX control inside the Wine package. Currently, to install applications that use Internet Explorer internally, such as Steam, the user has to download the Mozilla ActiveX control as a tar file and then manually register the DLL to get Wine to use it (see the Howto in the AppDB entry here: http://appdb.winehq.org/appview.php?versionId=1554 ) Modifying Wine to recognize when the Mozilla ActiveX Control is installed without having to register it manually should be easy enough, however distributing it with the Wine package or as a separate side package presents an unusual licensing issue. Now, the Mozilla ActiveX control is freely licensed, and we can redistribute it however we please. Unfortunately, to make it work in Wine we also need to use the dlls for the Microsoft Foundation Classes that it's written in such as msvcp70.dll, as Wine does not currently implement those. These files have an unusual license. Someone who owns the compiler (such as MSVC 7) is allowed to distribute them, however redistribution further from there isn't necessarily allowed, as the person receiving the file doesn't have a license to redistribute like the EULA for the compiler grants. This doesn't seem to prevent us from giving out the package with the DLL included, however users wouldn't be able to redistribute it. This sounds much like the way the situation is with the NVidia drivers. Would building the package be the right way to go here, with the ultimate destination being the restricted copyright repository in Ubuntu? Or is there something I'm overlooking here (perhaps reading the license wrong)? Thanks, Scott Ritchie

6 7

[BugZilla] adding usefull functionnalities
by Raphael 21 Nov '05

21 Nov '05

Hi, can we have a "Meta Bugs" fast access on "Task Lists" who group all known meta bugs ? (better than txt file i use) Thx Regards, Raphael

1 0

Re: PATCH: dlls/winsock/socket.h portability fix
by Alexandre Julliard 21 Nov '05

21 Nov '05

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > ChangeLog: > On some systems like FreeBSD, EAI_NODATA is defined in <lwres/netdb.h>, > so include this if present. Why isn't it in netdb.h? And if we get it from lwres shouldn't we then link to liblwres? -- Alexandre Julliard julliard(a)winehq.org

2 4

usb driver proxy
by Maris Paupe 21 Nov '05

21 Nov '05

Hi, First of all, sorry for my bad English. I have a USB device which doesn' t have a driver in linux, I wrote it as kernel module, but because I want to run windows software under wine which uses this device it seems that I will need to write something like proxy in wine (like audio and video drivers are written) to enable my software to use this device. Right now I am planning to rewite this driver using libusb and implement everything in wine's proxy. Maybe somebody have some dummy driver for purposes like this or I sould just take audio or some other driver and use it as starting point, maybe you have some useful suggestions to give me before I start?

7 9

KERNEL: parsing /proc/scsi/scsi
by Saulius Krasuckas 21 Nov '05

21 Nov '05

While running my wine I started getting this recently: $ ./wine --version | err:reg:SCSI_getprocentry SCSI type line scan count error | Wine 0.9.1 Next: $ uname -r | 2.6.14-1.1637_FC4 $ cat /proc/scsi/scsi | Attached devices: | Host: scsi0 Channel: 00 Id: 00 Lun: 00 | Vendor: PLEXTOR Model: DVDR PX-712A Rev: 1.04 | Type: CD-ROM ANSI SCSI revision: ffffffff Next: $ dmesg | grep -C1 PLEXTOR.*1.04 | scsi0 : SCSI host adapter emulation for IDE ATAPI devices | Vendor: PLEXTOR Model: DVDR PX-712A Rev: 1.04 | Type: CD-ROM ANSI SCSI revision: 00 Strange difference. If I search for a "ANSI SCSI revision" string, I get: $ grr "ANSI SCSI revision" linux-2.6.14/ | linux-2.6.14/drivers/block/acsi.c: printk(" ANSI SCSI revision: %02x", data[2] & 0x07); | linux-2.6.14/drivers/scsi/megaraid.c: " ANSI SCSI revision: %02x", scsi_inq[2] & 0x07); | linux-2.6.14/drivers/scsi/scsi_scan.c: printk(" ANSI SCSI revision: %02x", I am not sure, why this happens, as I see no code which forms "scsi/scsi" proc-file content, but still I think it is bug in our parser: $ grep -B6 "SCSI type line scan count error" dlls/kernel/oldconfig.c | result = fscanf( procfile, | " Type:%*3[ ]%32c%*1[ ]ANSI%*1[ ]SCSI%*1[ ]revision:%*1[ ]%d\n", | dev->type, | &dev->ansirev ); | if( result != 2 ) | { | ERR("SCSI type line scan count error\n"); where parser treats last number as a decimal one, while it is in hexadecimal format. I would appreaciate explanation, why dmesg and /proc/scsi/scsi writer behaves in slightly different ways.

2 1

Repeat message - Why was the included patch rejected?
by Robert Lunnon 21 Nov '05

21 Nov '05

This message never seemed to make it to the list so here is a resend ========================================================== Anyone know why this patch wasn't applied ? I don't know about anyone else but I'm still getting va_list undeclared. Bob ---------- Forwarded Message ---------- Subject: [winternl.h]Add missing header file Date: Friday 11 November 2005 03:29 From: Sütő Gergely <geri(a)aplusnet.hu> To: wine-patches(a)winehq.org ChangeLog: Add a missing stdarg.h includes. This is my first patch please check it! :) BYe: Geri_ ------------------------------------------------------- winternl_h.diff

2 2

Fwd: [winternl.h]Add missing header file
by Robert Lunnon 21 Nov '05

21 Nov '05

Anyone know why this patch wasn't applied ? I don't know about anyone else but I'm still getting va_list undeclared. Bob ---------- Forwarded Message ---------- Subject: [winternl.h]Add missing header file Date: Friday 11 November 2005 03:29 From: Sütő Gergely <geri(a)aplusnet.hu> To: wine-patches(a)winehq.org ChangeLog: Add a missing stdarg.h includes. This is my first patch please check it! :) BYe: Geri_ -------------------------------------------------------

4 3

Re: widl: Properly dereference the out parameter when copying
by Alexandre Julliard 21 Nov '05

21 Nov '05

James Hawkins <truiken(a)gmail.com> writes: > Anything wrong with this patch? > > Changelog > * Properly dereference the out parameter when copying. It seems to me that if you dereference the variable then you should remove the dereference in the typecast, otherwise the types won't match. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32: SHELL32_GetItemAttributes() [resend]
by Alexandre Julliard 21 Nov '05

21 Nov '05

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > Changelog: > correctly call HCR_GetFolderAttributes() in SHELL32_GetItemAttributes() It breaks the tests here: shlfolder.c:671: Test failed: SHGetPathFromIDList succeeded where it shouldn't! -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Add a test showing that SaveDC after GetDC should return 1
by Alexandre Julliard 21 Nov '05

21 Nov '05

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +todo("windows") > +{ /* XP returns COMPLEXREGION although dump_region reports only 1 rect */ > + ok(ret == SIMPLEREGION, "IntersectClipRect returned %d instead of SIMPLEREGION\n", ret); > +} It doesn't make sense to add a todo for Windows, we won't be able to fix the bug there... -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: wine/dlls/comctl32 syslink.c
by Thomas Weidenmueller 21 Nov '05

21 Nov '05

@@ -1666,9 +1712,8 @@ */ VOID SYSLINK_Register (void) { - WNDCLASSW wndClass; + WNDCLASSW wndClass = {0}; - ZeroMemory (&wndClass, sizeof(wndClass)); wndClass.style = CS_GLOBALCLASS | CS_VREDRAW | CS_HREDRAW; wndClass.lpfnWndProc = SysLinkWindowProc; wndClass.cbClsExtra = 0; Is there a reason this change wasn't applied? Calling ZeroMemory is slower and prevents certain optimizations by the compiler. - Thomas

2 1

Spelling error?
by Saulius Krasuckas 21 Nov '05

21 Nov '05

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 21 Nov '05

21 Nov '05

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 21 Nov '05

21 Nov '05

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 21 Nov '05

21 Nov '05

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 21 Nov '05

21 Nov '05

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 21 Nov '05

21 Nov '05

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 21 Nov '05

21 Nov '05

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 21 Nov '05

21 Nov '05

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 20 Nov '05

20 Nov '05

> 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 20 Nov '05

20 Nov '05

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

Re: PATCH: long registry lines loading
by Andreas Mohr 20 Nov '05

20 Nov '05

Hi, On Sun, Nov 20, 2005 at 05:45:13PM +0100, Marcus Meissner wrote: > I have this patch proposal, but I fear it might not fly with Alexandre ;) Not only with Alexandre, I'm afraid ;) Why not follow a dual strategy: use a static buffer for <= MAX_PATH and use a malloc()ed buffer if it exceeds that size? (ok, scrap that, static plus malloc() is a BAD idea:) Or, since the original buffer variable was static anyway, you could just *always* (re-)use an malloc()ed buffer and *grow* it whenever the previous size was to small... I haven't looked too closely at the code, but repeated malloc()/free() in "fast-as-lightning" registry code sounds like a terrible solution that can be easily transformed into something better here, it seems. Andreas

1 0

MBR was destroyed
by seorge 20 Nov '05

20 Nov '05

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.

3 2

Re: Licensing and technical issues with a Wine package that includes the Mozilla ActiveX Control
by Mike Hearn 20 Nov '05

20 Nov '05

On Sun, 20 Nov 2005 12:55:30 +0100, Stephan Hermann wrote: > As I understand the Howto, Steam somehow needs this mfc dll, but doens't > ship it. That can mean, that the Steam developer don't have the rights > to distribute it, which sounds a bit strange to me. If they don't > deliver a vital dll for their software, they have a problem, which we or > better you should not solve, with shipping any propietary software in > the wine app. Windows comes with the MFC DLL and has done for yonks, so it's effectively an OS component now.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel