Re: Will ROS and WINE still be steady be synchronized ?
Shachar Shemesh wrote: 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: Just to make it clear, as far as I can see it, even with the above, it is still illegal to accept code from RoS (you are not allowed to copy code from the MS source code, or even from your own effort of translating the assembly to C, without violating copyright). All I'm saying is that the rules are not as strict as we sometimes play them to be. Shachar
Re: Will ROS and WINE still be steady be synchronized ?
On 9/21/07, Shachar Shemesh [EMAIL PROTECTED] wrote: Shachar Shemesh wrote: 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: Just to make it clear, as far as I can see it, even with the above, it is still illegal to accept code from RoS (you are not allowed to copy code from the MS source code, or even from your own effort of translating the assembly to C, without violating copyright). All I'm saying is that the rules are not as strict as we sometimes play them to be. The article at [1] provides interesting information regarding reverse engineering of all types. More importantly, the author provides a list of cases that provide legal precedence for the legality (or lack thereof) of reverse engineering. The most important thing to keep in mind when considering the legality of reverse engineering is that there is no fine line when it comes to the act, and any new case can overturn all the legal precedence that comes before it. The Wine project has succeeded thus far without using reverse engineering, and will continue to do so, so there's no reason to take the legal risk of accepting code form the ReactOS project, or from anyone that has seen or reverse engineered Microsoft code, clean room or otherwise. [1] http://www.jenkins-ip.com/serv/serv_6.htm -- James Hawkins
Re: Will ROS and WINE still be steady be synchronized ?
On 9/20/07, Shachar Shemesh [EMAIL PROTECTED] wrote: Shachar Shemesh wrote: 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: Just to make it clear, as far as I can see it, even with the above, it is still illegal to accept code from RoS (you are not allowed to copy code from the MS source code, or even from your own effort of translating the assembly to C, without violating copyright). OK then, we seem to agree. All I'm saying is that the rules are not as strict as we sometimes play them to be. I'm not trying to make any generalizations here, just trying to explain why Wine can't safely accept ReactOS code. - Dan
Re: Will ROS and WINE still be steady be synchronized ?
On 9/21/07, Dan Kegel [EMAIL PROTECTED] wrote: (the two projects were the same originally, and split apart only after the world noticed just how illegal ReactOS's practices were). These broad generalizations or downright libel statements prove more inflammatory that then accusations of developer taint. I take great objection to this as a lot of this crap happened under my watch. 1. Some developers practices might not be legal in the US. The project has an policy statement that most developers followed. Others did not. It happens. It was never taken to court and ultimately those developers left anyway. If you know of a function in ReactOS that looks suspicious feel free to send a note their way. I am sure they will remove it. What happens if I say Function foo looks like its dirty and it made it in the Wine tree Is wine forever tainted? Can you point out case-law or a standard ANYWHERE ReactOS needs to follow to make the Wine people happy? I can point to one standard and Julliard already said he did not agree with it. http://www.gnu.org/prep/standards/ They even have a whole page for people that have SEEN proprietary sources http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#Reading-Non_002dFree-Code 2. To Date Wine does not have a clearly identifiable policy statement about what is Kosher and what is not and EVER FREAKING WEEK someone asks a policy related question on wine-devel. Can I use ReactOS code? Do we follow the same rules as the GNU coding standards? What is clean room reverse engineering? What is the Audit thing I keep hearing about? 3. How about, rather than blackballing a whole project or group and causing guilt by association, we use the same standards for everyone when submitting patches, codify them and let that be that. What happens the day Wine gets a patch from a @microsoft.com email? Do we blackball them if their corporate policy changes to allow a contribution. I mean you know they make a compiler right? You know they also submit patches to GCC for Interix right? I hope to God we have a standard in place by then and a webform that allows that person to say I never had access to windows source that had analogous functionality. 4. Do you think Vlad the Reverser from Russia sending a patch to wine-patches is going to preface his patches saying I reversed this or I copied this? No hes going to submit it and Julliard is going to have to make a judgment call based upon if he knows the person, the quality of the code and the planarity alignment. I could go on but I am just ranting and angry because this keeps coming up and the solution seems clear enough. Can we at least, while the crickets chirp on the audit, get the SFLC to publish some bloody standards we should all follow? Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Will ROS and WINE still be steady be synchronized ?
On 9/21/07, Dan Kegel [EMAIL PROTECTED] wrote: I'm not trying to make any generalizations here, just trying to explain why Wine can't safely accept ReactOS code. Sorry about my last post then. I should not have added more statements that are inflammatory with harsh rhetoric. I would be happy to write an FAQ explaining this matter as I understand the clean-room requirements and that ReactOS does not meet them. My objection to doing this right now is that I think the SFLC should be the ones to write the standard and every single time this comes up, members of the Wine project take it upon themselves to define what is legal and what is not and accuse the ReactOS team of behaving in a way that is not legal. That may very well be, but until our legal team actually says so, all it does is hurt the PR for ReactOS and make the Wine developers look like they have it in for ReactOS Project. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread
Am Donnerstag, 20. September 2007 03:49:40 schrieb Carroll Vance: I have tested this with a driver I made and it seemed to work fine. I don't know much about ntoskrnl.exe, but if you have a test driver, you may want to include it in the patch. Other libraries have a set of regression tests in dlls/lib/tests . ntoskrnl.exe doesn't have any yet, but I don't know if that is a policy or just because no one started it yet. signature.asc Description: This is a digitally signed message part.
Re: services.exe[3/3]: start a local RPC server and make advapi32 connect/disconnect to it on service manager handle creation/destruction
Mikolaj Zalewski wrote:
+/* Compatible with Windows function 0x0f */
+DWORD svcctl_OpenSCManagerW(
+SvcCtlRpcHandle rpc_handle,
+[in,unique,string] LPCWSTR MachineName,
+[in,unique,string] LPCWSTR DatabaseName,
The string attribute should be redundant as LPCWSTR should already be
declared as a string type. I also noticed this redundancy in your fourth
services patch.
+if ((err = RpcServerInqBindings(pbindingVector)) != ERROR_SUCCESS)
+{
+WINE_ERR(RpcServerInqBindings failed with error %u\n, err);
+return err;
+}
What's the purpose of this? You don't actually use the binding vector
anywhere.
--
Rob Shearman
Re: Will ROS and WINE still be steady be synchronized ?
On 9/21/07, Steven Edwards [EMAIL PROTECTED] wrote: I could go on but I am just ranting and angry because this keeps coming up and the solution seems clear enough. Can we at least, while the crickets chirp on the audit, get the SFLC to publish some bloody standards we should all follow? Hear, hear! I believe this would make an excellent topic at Wineconf. Jeremy, how about a status report there? - Dan
Re: Will ROS and WINE still be steady be synchronized ?
On 9/21/07, Steven Edwards [EMAIL PROTECTED] wrote: On 9/21/07, Dan Kegel [EMAIL PROTECTED] wrote: I'm not trying to make any generalizations here, just trying to explain why Wine can't safely accept ReactOS code. Sorry about my last post then. I should not have added more statements that are inflammatory with harsh rhetoric. But it was a good read nonetheless. I would be happy to write an FAQ explaining this matter as I understand the clean-room requirements and that ReactOS does not meet them. My objection to doing this right now is that I think the SFLC should be the ones to write the standard and every single time this comes up, members of the Wine project take it upon themselves to define what is legal and what is not and accuse the ReactOS team of behaving in a way that is not legal. The questions certainly do come up frequently. We can't wait forever for the SFLC, so perhaps it would be good for you to draft an FAQ. We could run it by them before posting it. Alexandre? - Dan
Re: Will ROS and WINE still be steady be synchronized ?
Dan Kegel wrote: On 9/21/07, Steven Edwards [EMAIL PROTECTED] wrote: I could go on but I am just ranting and angry because this keeps coming up and the solution seems clear enough. Can we at least, while the crickets chirp on the audit, get the SFLC to publish some bloody standards we should all follow? Hear, hear! I believe this would make an excellent topic at Wineconf. Jeremy, how about a status report there? Good idea! We'll make that a useful deadline for bringing forward the ideas we've been working with the SFLC for the past year or two. (And yes, I'm painfully aware it's been a long time). I'll post a separate note on the state of the SFLC wrt Wine as I see it as well. Cheers, Jeremy
WineD3D patch submission
Hi all,
A week or so ago I tried to get a game working in WINE (Titan Quest),
however it seems it really needs a proper DIB engine before it'll be
playable.
Anyways, in my attempt to get it working I fixed up some issues w/
IWineD3DDeviceImpl_UpdateSurface.c in dlls/wined3d, not entirely sure
how you guys do things around here so I thought i'd just post my changes
to the function in this mailing list and you can do with it what you
want. (Note: it actually has a few different methods of doing one
thing, enclosed in macro blocks to toggle between them. Technically the
first one should work (i think :\) once you guys properly implement
surface locking/unlocking, and it's 'simplest', but the last one is the
only one that actually works properly (using standard OpenGL calls).
You'll probably have to clean up the code to meet your coding standards
/ etc, maybe remove the custom byte size calculation of compressed
images, and some other things - but the functionality is there... i
also fixed the existing code that didn't actually do what it was
supposed to, heh.
Regards,
Mitchell Wheeler
static HRESULT WINAPI IWineD3DDeviceImpl_UpdateSurface(IWineD3DDevice
*iface, IWineD3DSurface *pSourceSurface, CONST RECT* pSourceRect,
IWineD3DSurface *pDestinationSurface, CONST POINT* pDestPoint) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface;
/** TODO: remove casts to IWineD3DSurfaceImpl
* NOTE: move code to surface to accomplish this
/
IWineD3DSurfaceImpl *pSrcSurface = (IWineD3DSurfaceImpl
*)pSourceSurface;
IWineD3DSurfaceImpl *pDestSurface =
(IWineD3DSurfaceImpl*)pDestinationSurface;
int srcWidth, srcHeight;
unsigned int srcSurfaceWidth, srcSurfaceHeight, destSurfaceWidth,
destSurfaceHeight;
WINED3DFORMAT destFormat, srcFormat;
int srcLeft, srcTop, destLeft, destTop;
WINED3DPOOL srcPool, destPool;
int offset= 0;
int rowoffset = 0; /* how many bytes to add onto the end of a row to
wraparound to the beginning of the next */
glDescriptor *glDescription = NULL, *glSrcDescription = NULL;
GLenum dummy;
int bpp;
UINT destByteSize = 0, srcByteSize = 0;
int destPixelByteSize = 0, srcPixelByteSize = 0;
CONVERT_TYPES convert = NO_CONVERSION;
WINED3DSURFACE_DESC winedesc;
TRACE((%p) : Source (%p) Rect (%p) Destination (%p) Point(%p)\n,
This, pSourceSurface, pSourceRect, pDestinationSurface, pDestPoint);
memset(winedesc, 0, sizeof(winedesc));
winedesc.Width = srcSurfaceWidth;
winedesc.Height = srcSurfaceHeight;
winedesc.Pool = srcPool;
winedesc.Format = srcFormat;
winedesc.Size = srcByteSize;
IWineD3DSurface_GetDesc(pSourceSurface, winedesc);
winedesc.Width = destSurfaceWidth;
winedesc.Height = destSurfaceHeight;
winedesc.Pool = destPool;
winedesc.Format = destFormat;
winedesc.Size = destByteSize;
IWineD3DSurface_GetDesc(pDestinationSurface, winedesc);
if(srcPool != WINED3DPOOL_SYSTEMMEM || destPool !=
WINED3DPOOL_DEFAULT){
WARN(source %p must be SYSTEMMEM and dest %p must be DEFAULT,
returning WINED3DERR_INVALIDCALL\n, pSourceSurface, pDestinationSurface);
return WINED3DERR_INVALIDCALL;
}
/* This call loads the opengl surface directly, instead of copying
the surface to the
* destination's sysmem copy. If surface conversion is needed, use
BltFast instead to
* copy in sysmem and use regular surface loading.
*/
d3dfmt_get_conv((IWineD3DSurfaceImpl *) pDestinationSurface, FALSE,
TRUE,
dummy, dummy, dummy, convert, bpp, FALSE);
if(convert != NO_CONVERSION) {
return IWineD3DSurface_BltFast(pDestinationSurface,
pDestPoint ? pDestPoint-x : 0,
pDestPoint ? pDestPoint-y : 0,
pSourceSurface, (RECT *)
pSourceRect, 0);
}
if (destFormat == WINED3DFMT_UNKNOWN) {
TRACE((%p) : Converting destination surface from
WINED3DFMT_UNKNOWN to the source format\n, This);
IWineD3DSurface_SetFormat(pDestinationSurface, srcFormat);
/* Get the update surface description */
IWineD3DSurface_GetDesc(pDestinationSurface, winedesc);
}
ActivateContext(This, This-lastActiveRenderTarget,
CTXUSAGE_RESOURCELOAD);
ENTER_GL();
if (GL_SUPPORT(ARB_MULTITEXTURE)) {
GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB));
checkGLcall(glActiveTextureARB);
}
/* Make sure the surface is loaded and up to date */
IWineD3DSurface_PreLoad(pDestinationSurface);
IWineD3DSurface_GetGlDesc(pDestinationSurface, glDescription);
IWineD3DSurface_GetGlDesc(pDestinationSurface, glSrcDescription);
/* this needs to be done in lines if the sourceRect != the
sourceWidth */
srcWidth= pSourceRect? pSourceRect-right -
