Re: setupapi(8/22): Implement SetupDiCreateDeviceInfoW
Juan Lang [EMAIL PROTECTED] writes:
+static DWORD SETUPDI_DevNameToDevID(LPCWSTR devName)
+{
+LPCWSTR ptr;
+DWORD devNameLen = lstrlenW(devName), devInst = 0;
+BOOL valid = TRUE;
+
+TRACE(%s\n, debugstr_w(devName));
+for (ptr = devName; valid *ptr ptr - devName devNameLen; )
+{
+ if (isdigitW(*ptr))
+ {
+ devInst = 8;
This won't do what you want. You'd need *= 10 if the id is really
stored in decimal, though looks more like it should be in hex.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Alexandre Julliard : wordpad.exe: We can now store binary files in the repository.
Markus Amsler [EMAIL PROTECTED] writes: So we can also add ttf fonts and get rid of the fontforge dependency? No, I don't think ttf is an appropriate source format. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winex11.drv/wintab32[3/5]: make wintab strings in winex11.drv Unicode, implement WTInfoW
Mikolaj Zalewski [EMAIL PROTECTED] writes:
@@ -305,8 +312,8 @@ void X11DRV_LoadTabletInfo(HWND hwnddefault)
hwndTabletDefault = hwnddefault;
/* Do base initializaion */
-strcpy(gSysContext.lcName, Wine Tablet Context);
-strcpy(gSysDevice.NAME,Wine Tablet Device);
+MultiByteToWideChar(CP_UTF8, 0, Wine Tablet Context, -1,
gSysContext.lcName, WT_MAX_NAME_LEN);
+MultiByteToWideChar(CP_UTF8, 0, Wine Tablet Device, -1,
gSysDevice.NAME, WT_MAX_NAME_LEN);
You should define Unicode constants directly, there's no need to
convert at run-time.
@@ -695,10 +716,12 @@ int X11DRV_AttachEventQueueToTablet(HWND hOwner)
X11DRV_expect_error(data-display,Tablet_ErrorHandler,NULL);
for (cur_loop=0; cur_loop gNumCursors; cur_loop++)
{
+char cursorNameA[WT_MAX_NAME_LEN];
intevent_number=0;
+WideCharToMultiByte(CP_UNIXCP, 0, gSysCursor[cur_loop].NAME, -1,
cursorNameA, WT_MAX_NAME_LEN, NULL, NULL);
for (loop=0; loop num_devices; loop ++)
-if (strcmp(devices[loop].name,gSysCursor[cur_loop].NAME)==0)
+if (strncmp(devices[loop].name, cursorNameA, WT_MAX_NAME_LEN)==0)
This doesn't look right; if the name overflows the buffer we shouldn't
simply match against a truncated string.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: setupapi(8/22): Implement SetupDiCreateDeviceInfoW
This won't do what you want. You'd need *= 10 if the id is really stored in decimal, though looks more like it should be in hex. You're right. It is decimal. Thanks. --Juan
Re: WineD3D: better video memory reporting
Your patch appears empty: Type: text/x-diff Size: 0 bytes --Juan
[PATCH] fix small spelling mistakes
Hi Peter, correct spelling of iff - if Just so you know, iff is a common abbreviation meaning if and only if. I don't think that's any clearer in the cases you modified, so I think your patch is fine, I just thought you (and others) might be interested. --Juan
Re: WineD3D: better video memory reporting
On 9/20/07, Juan Lang [EMAIL PROTECTED] wrote: Your patch appears empty: Came through ok here. --John Klehm
Re: Will ROS and WINE still be steady be synchronized ?
Alexander Nicolaysen Sørnes wrote: ReactOS has been known for disassembling Microsoft binaries, which is illegal in some countries, notably the US. As far as I understand this, if I disassemble Microsoft binaries (it is legal in Israel), then the resulting knowledge is legal to use - anywhere (in other words - the only one who can be sued is me, and the jurisdiction is Israel, where the action is legal). Do RoS people disassemble binaries in countries in which it is illegal to disassemble them? Shachar
Re: [PATCH] fix small spelling mistakes
On Thursday 20 September 2007, Juan Lang wrote: Hi Peter, correct spelling of iff - if Just so you know, iff is a common abbreviation meaning if and only if. I don't think that's any clearer in the cases you modified, so I think your patch is fine, I just thought you (and others) might be interested. --Juan Hi, you are right, i never heard about using it as a abbreviation for if and only if. Maybe i should have tried a dictionary first before fixing it :-) Thanks telling me Greetings Peter
Re: Implemented PsCreateSystemThread in ntoskrnl.exe
Hi Carroll, +if (ProcessHandle!=0) + localThreadHandle = CreateRemoteThread(ProcessHandle,0,0,StartRoutine,StartContext,0,ThreadId); +else localThreadHandle = CreateThread(0,0,StartRoutine,StartContext,0,ThreadId); + +if (localThreadHandle==0) return STATUS_SEVERITY_ERROR; You should use NtCreateThread rather than CreateThread. It also returns a proper status, so you don't have to guess like you do here. --Juan
Re: Implemented PsCreateSystemThread in ntoskrnl.exe
Juan Lang wrote: Hi Carroll, +if (ProcessHandle!=0) + localThreadHandle = CreateRemoteThread(ProcessHandle,0,0,StartRoutine,StartContext,0,ThreadId); +else localThreadHandle = CreateThread(0,0,StartRoutine,StartContext,0,ThreadId); + +if (localThreadHandle==0) return STATUS_SEVERITY_ERROR; You should use NtCreateThread rather than CreateThread. It also returns a proper status, so you don't have to guess like you do here. Actually, NtCreateThread is too low-level and so isn't implemented in Wine. RtlCreateUserThread might be better to use though. -- Rob Shearman
Re: Implemented PsCreateSystemThread in ntoskrnl.exe
Actually, NtCreateThread is too low-level and so isn't implemented in Wine. RtlCreateUserThread might be better to use though. Whoops :) Thanks, Rob. --Juan
Re: Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for joystick buttons
Antonio Cuni wrote: At least one game (Pro Evolution Soccer 6) rely on the pguid field of the DIOBJECTDATAFORMAT struct to respond to joystick button's events. Setting pguid to GUID_Button solves the problem. 2007-09-20 Antonio Cuni [EMAIL PROTECTED] * dlls/dinput/joystick_linux.c, dlls/dinput/joystick_linuxinput.c Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for joystick buttons Thank you for the patch. I have few comments about it: -- /tmp/wine-0.9.45/dlls/dinput/joystick_linux.c 2007-09-14 19:30:55.0 +0200 +++ ./joystick_linux.c2007-09-20 17:02:15.0 +0200 You should diff from the top of the tree (above line should say dlls/dinput/joystick_linux.c). +df-rgodf[idx].pguid = GUID_Button; // some games require the GUID to be GUID_Button C++ comments are not allowed in Wine. Please put comments above the code. newDevice-buttons[i] = 0x80 | newDevice-numButtons; + df-rgodf[idx].pguid = GUID_Button; // some games require the GUID to be GUID_Button df-rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(newDevice-numButtons++) | DIDFT_PSHBUTTON; Please don't use tabs. Use spaces to keep formating. Vitaliy.
Re: Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for joystick buttons
On 9/20/07, Antonio Cuni [EMAIL PROTECTED] wrote: At least one game (Pro Evolution Soccer 6) rely on the pguid field of the DIOBJECTDATAFORMAT struct to respond to joystick button's events. Setting pguid to GUID_Button solves the problem. 2007-09-20 Antonio Cuni [EMAIL PROTECTED] * dlls/dinput/joystick_linux.c, dlls/dinput/joystick_linuxinput.c Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for joystick buttons +df-rgodf[idx].pguid = GUID_Button; // some games require the GUID to be + df-rgodf[idx].pguid = GUID_Button; // some games require the GUID to be GUID_Button You need to use C style comments /* */ Regards =), --John Klehm
Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread
Carroll Vance [EMAIL PROTECTED] wrote: I have implemented PsCreateSystemThread in ntoskrnl.exe. This API i have found used by programs like nProtect gameguard, and is a pretty commonly used kernel api. This either ends up calling CreateThread or CreateRemoteThread depending on if a process handle was provided. You can call CreateRemoteThread without any checks for the process handle. This is my first patch, I read over the dev docs and patch format, I hope I did not miss anything. I have tested this with a driver I made and it seemed to work fine. Your patch mixes tabs and spaces on the same line, that makes formatting messy. Also if you could add spaces around '!=' and '==' in if statements that would make the code slightly more readable. -- Dmitry.
re: Will ROS and WINE still be steady be synchronized ?
Shachar Shemesh wrote: As far as I understand this, if I disassemble Microsoft binaries (it is legal in Israel), then the resulting knowledge is legal to use - anywhere (in other words - the only one who can be sued is me, and the jurisdiction is Israel, where the action is legal). I am not a lawyer, but I bet you're wrong there. The disassembled code is probably considered a copy, using it could be a copyright violation, and if any such code snuck into Wine, we'd have to go rip it out at great cost. - Dan
Re: Will ROS and WINE still be steady be synchronized ?
Dan Kegel wrote: I am not a lawyer, but I bet you're wrong there. The disassembled code is probably considered a copy, I'm not talking about moving disassembled code into our code. That is a copyright violation in Israel too. I'm talking about disassembling code in order to figure out what it does, and then reimplementing that (with or without going into the extremes of clean room). Do the RoS guys do the former? Shachar
Re: Will ROS and WINE still be steady be synchronized ?
On 9/20/07, Shachar Shemesh [EMAIL PROTECTED] wrote: I'm not talking about moving disassembled code into our code. That is a copyright violation in Israel too. I'm talking about disassembling code in order to figure out what it does, and then reimplementing that (with or without going into the extremes of clean room). (Again, I am not a lawyer.) I think this is legal in the US *only* when applied to interfaces, not to innards. Do the RoS guys do the former? For their official policy, see http://www.reactos.org/en/dev_legalreview.html But also see http://www.reactos.org/wiki/index.php/TinyKRNL Here's the problem with accepting code from ReactOS: they share code and developers with the TinyKRNL project (the two projects were the same originally, and split apart only after the world noticed just how illegal ReactOS's practices were). TinyKRNL's official policy is anything goes, so it wouldn't surprise me if people on that project simply retyped stuff they saw in stolen copies of the real Microsoft Windows source code. ReachOS's official policy says in effect there's no such thing as a tainted developer, so all TinyKRNL developers are welcome to submit code to ReactOS; and any not-obviously-problematic code in TinyKRNL can be imported into ReactOS. While the above is a crass oversimplification, and I'm sure the ReactOS people will want to correct any errors I made in it, it seems clear to me that the fig leaf ReactOS is standing behind is a bit too small for comfort. Wine does well to steer clear of ReactOS code. We've gone over this about a dozen times. Can we get back to programming Wine now (cleanly)? - Dan
Re: Will ROS and WINE still be steady be synchronized ?
Dan Kegel wrote: We've gone over this about a dozen times. Can we get back to programming Wine now (cleanly)? - Dan Here's the law as I know it. As far as I know, it is quite identical in the US and in Israel in that regard: - Any trade secret (say, algorithm, interface, subbehavior) loses its secret status the moment it is reversed engineered from a legally obtained copy. Once it loses its secret status, it is obviously legal to cleanly reimplemenet it. - Any trade secret loses its status the moment it is public. As far as I understand it, the MS source code that was leaked has no trade secret protection any more, and it is entirely legal for a Wine hacker to look at it in order to find out, for example, why a certain combination of parameters, when sent to a certain function, causes Windows to do something unexpected. It is NOT legal to copy code into Wine from it, as that code is still copyrighted. - Interfaces are not copy protectable. This means that it is, in principle, legal to copy a file that only has interface definitions (say, a header file) into Wine. We don't do it, and for a good reason (why risk it for such a small gain), but it is legal. - A programmer is only tainted if she signed an NDA or a non-compete. Even then, it's a contractual dispute, not a criminal dispute, whether she is allowed to work on Wine. Merely looking at publicly available code does not taint a programmer (this is unlike the IBM BIOS case, where they gave the BIOS source code under NDA, and thus retained trade secret status for it). Shachar
