Dmitry,
On Tue, Nov 18, 2008 at 2:22 AM, Dmitry Timoshkov
<dmitry(a)codeweavers.com> wrote:
> http://www.reactos.org/archives/public/ros-diffs/2008-November/027021.html
>
> Please stop copying Wine code without any copyright and source
> reference into reactos. This became very bad practice from your
> side during last years.
I have no power with the ReactOS project other than to ask and try to
get policy changed in a democratic manner. I've made the case for the
ReactOS to do a better job at proper attribution in code that is
imported based on feedback from you in the past. In fact, just
yesterday I replied to ros-dev proposing some guidelines for how to
handle code imported from Wine. There is nothing more I can do.
I have CC'd Alexandre and Jeremy for there thoughts on the subject. I
welcome feedback from the Software Freedom Law Center or the FSF with
reguards to this issue because on one hand I understand the
attribution is important but on the other hand ReactOS is persona
non-grata with Wine. Given Wine's reluctance to accept any
contributions from ReactOS developers, totally based on guilt by
assocation I think its in your best interested not to be credited. The
Software is still being released under the terms you granted so I
don't see a major violation.
>From the LGPL preamble:
"...Also, if the library is modified by someone else and passed on,
the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others."
Clearly the ReactOS developer is doing you a favor by not hurting your
reputation if ReactOS is as Toxic as Wine makes it out to be.
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
So we've been invited to SCALE and I'm wondering whether any of the devs can
actually make it. Arty is a logical choice because he's so close and we
might be able to pull in some community members who are close by if we can
only get one dev there. We'd get a booth on the show floor which includes
table, chairs, power, ethernet drop, and 3-5 passes to the show. Are we
going to be able to make it this year at all?
May I ask why those if (!Info) checks are required? To me it makes no
sense to call those APIs with the cruicial, mandatory working (and in
one case the only) parameter being NULL, and I would put an ASSERT
(Info) there to catch bad callers and fix them.
WBR,
Aleksey.
On Nov 18, 2008, at 8:36 AM, jimtabor(a)svn.reactos.org wrote:
> Author: jimtabor
> Date: Mon Nov 17 23:36:19 2008
> New Revision: 37436
>
> UINT
> FASTCALL
> DIB_BitmapMaxBitsSize( PBITMAPINFO Info, UINT ScanLines )
> {
> UINT MaxBits = 0;
> +
> + if (!Info) return 0;
>
>
> +UINT
> +FASTCALL
> +DIB_BitmapBitsSize( PBITMAPINFO Info )
> +{
> + UINT Ret;
> +
> + if (!Info) return 0;
This is just getting repetitive:
[WIDL] obj-i386\include\reactos\idl\lsa_c.c
include\reactos\idl\lsa.idl:17: Error: NTSTATUS: redefinition error;
original definition was at ( ť:
21
mingw32-make: *** [obj-i386\include\reactos\idl\lsa_c.c] Error 1
mingw32-make: *** Waiting for unfinished jobs....
[WIDL] obj-i386\include\reactos\idl\eventlogrpc_c.c
include\reactos\idl\eventlogrpc.idl:7: Error: NTSTATUS: redefinition error;
original definition was
at Ş■.:21
mingw32-make: *** [obj-i386\include\reactos\idl\eventlogrpc_c.c] Error 1
With all due respect, Eric, would you be so kind and test your commits on
more OS than your PC/buildbot???
Is it not time to start getting rid of IsBadWritePtr and friends?
I don't see a good reason for these in our own code, especially when we can just use SEH directly.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of greatlrd(a)svn.reactos.org
Sent: 13 November 2008 19:52
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [greatlrd] 37343: Bugfix : Do not link to LPDDRAWI_DIRECTDRAW_INT->lpLink when we do not have any LPDDRAWI_DIRECTDRAW_INT->lpLcl
Author: greatlrd
Date: Thu Nov 13 13:52:20 2008
New Revision: 37343
URL: http://svn.reactos.org/svn/reactos?rev=37343&view=rev
Log:
Bugfix : Do not link to LPDDRAWI_DIRECTDRAW_INT->lpLink when we do not have any LPDDRAWI_DIRECTDRAW_INT->lpLcl
Modified:
branches/reactx/reactos/dll/directx/ddraw/startup.c
Modified: branches/reactx/reactos/dll/directx/ddraw/startup.c
URL: http://svn.reactos.org/svn/reactos/branches/reactx/reactos/dll/directx/ddra…
==============================================================================
--- branches/reactx/reactos/dll/directx/ddraw/startup.c [iso-8859-1] (original)
+++ branches/reactx/reactos/dll/directx/ddraw/startup.c [iso-8859-1] Thu Nov 13 13:52:20 2008
@@ -33,8 +33,8 @@
This = (LPDDRAWI_DIRECTDRAW_INT)*pIface;
- /* fixme linking too second link when we shall not doing it */
- if (IsBadReadPtr(This,sizeof(LPDIRECTDRAW)))
+ if ( (IsBadWritePtr(This,sizeof(LPDDRAWI_DIRECTDRAW_INT)) != 0) ||
+ (IsBadWritePtr(This->lpLcl,sizeof(LPDDRAWI_DIRECTDRAW_LCL)) != 0) )
{
/* We do not have a DirectDraw interface, we need alloc it*/
LPDDRAWI_DIRECTDRAW_INT memThis;
Since revisions 37313-37314 i observe repetitive problems with WIDL. Every
time WIDL is called by our BE, it throws an exception:
Faulting application widl.exe, version 0.0.0.0, time stamp 0x491c610d,
faulting module widl.exe, version 0.0.0.0, time stamp 0x491c610d, exception
code 0xc0000005, fault offset 0x00005f0a, process id 0x17f8, application
start time 0x01c945b3aefa8530.
> [WIDL] obj-i386\include\reactos\idl\svcctl_s.c
> [WIDL] obj-i386\include\reactos\idl\svcctl_s.h
> mingw32-make: *** Waiting for unfinished jobs....
> mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.h] Error
-1073741819 (0xC0000005)
> mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.c] Error
-1073741819 (0xC0000005)
Reverting revisions 37313 and 37314 fixes this problem. Apart from me, this
issue been noted by dreimer, encoded and Christoph_vW. Dunno about
Christoph, but me, dreimer and encoded are using Vista/2008. I couldnt
replicate this issue on XP/2003 though.
Hi folks,
during the development of the 1st-stage-GUI-setup I experienced some problems
with physical drive detection with reactos api (because it's fairly
incomplete - it works under windows). To continue the development and to
bring more benefits I want to make following suggestion. Sooner or later we
need a drive/volume/partition management tool, so i will continue with this
basing on the usetup code and replaced later by working reactos api calls.
So we can use this tool to determine the current harddisk(s) layout(s),
create/delete partitions, format with different file systems and
show/install/configure the current boot loader. Later I can use this
functions to handle the drives during installation process in a similiar way.
What do you think about this plan?
Matt
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
Hi,
> Todo: Get it at the end of the executable, so we can safely remove it.
I think it can be safely removed from inside of the executable — just
wasting some address space.