Hi!
since 2013 is almost over, it is time to make some plans for 2014.
My primary goals for 2014 are:
- Completing the user account management, user logon and password change.
- Fixing winlogon.exe in order to enable users to lock and unlock the
computer and to change their identity (log-off and log-on again).
- Fix potential bugs in userenv.dll. We need to get rid of the
administrator logon hack in syssetup.dll.
- Fix the system shutdown: We need to terminate applications and
services before the machine shuts down.
Secondary goals are:
- Implement PNP support for scsiport.sys.
- Improvements to PNP and driver installation.
- Get some legacy hardware working (parallel port, PCMCIA).
The items of this list and their priorities are not fixed. I reserverve
the right to make changes to this list or to work on something entirely
different, without prior notice.
Happy new year!
Regards
Eric
Hi,
this message is a bit provocative, but please don't be offended by it.
You all did a wonderful work during this year. Thank you!
It's very good to see the work is going on. Just for fun, when I had
spare 15 minutes, I decided to check, what was done in the win32
subsystem during this year by the major, respectable and very old time
ReactOS developer, and whether my proposal with Arwinss still stands or not.
Here is what I found: (analyzing ~ 62 commits by jimtabor):
- 25 revisions: Fixes/hacks of our code (ReactOS-specific bug, works in
Wine, sometimes says in comments "//// ReactOS : Justin Case something
goes wrong.") (revs 58528, 58562, 58563, 58633, 58773, 58999, 59000,
59201, 60054, 60587, 60590, 60592, 60622, 60626, 60659, 60676, 60677,
60881, 61078, 61079, 61142, 61250, 61251, 61292, 61458)
- 13 revisions: Syncs with Wine (revs 59157, 59158, 59159, 60763, 60784,
60807, 60820, 60858, 60863, 60865, 60867, 61244, 61422)
- 14 revisions: Own code development or rewriting old code, some of
which might have been derived from ancient versions of Wine.
(60387, 60389, 60394, 60539, 60599, 60602, 60660, 60682, 60683, 60684,
60718, 60883, 60976, 60992)
- 1 revision: attempt to fix a bug found in Wine (revision 60054, issue
CORE-6024)
You don't need to be a scientist to see that 61% of the changes went
into fixing ReactOS specific bugs or just bringing in newer Wine code to
fix old Wine bugs. Remaining 22% of efforts was spent on actually
developing our own, assumingly better code, and just 1 revision was
spent on such a glorious thing as fixing Wine's bug.
ReactOS is a just for fun type of project, so I highly appreciate that
efforts were put into all of the above!
However, I still think that it would be beneficial if someone would put
similar efforts into Arwinss to eliminate the need to bring in hacks and
fix stuff which works in Wine for years already, and focus on developing
only those parts which we obviously can't share (GDI, hardware
accelerated graphics, whatever else).
I lack time to do this myself, but if anyone volunteers I would be glad
to help, share my experience and think up of interesting tasks. Like,
getting Arwinss to work in Windows 2003 instead of its native subsystem,
which would be a nice test.
Regards,
Aleksey Bragin
On 2013-12-25 23:47, pschweitzer(a)svn.reactos.org wrote:
> +TryWithVolumeName:
> + /* If we didn't find anything, try differently */
> + if (DeviceLength < 2 * sizeof(WCHAR) || DeviceString[2] != L':')
This looks like a buffer overrun. Did you mean < 3 * sizeof(WCHAR)?
A pity.
-------- Original Message --------
Subject: Your stand proposal for ReactOS has been rejected
Date: Mon, 16 Dec 2013 22:28:19 +0100 (CET)
From: FOSDEM Stands Team <stands(a)fosdem.org>
To: Aleksey Bragin <aleksey(a)reactos.org>
Hi Aleksey,
The FOSDEM stands team is sorry to have to inform you that your request
for a stand for ReactOS has been rejected.
We have received almost twice as many proposals as we could accept,
and we regret not being able to give everyone a stand.
We hope to see you at FOSDEM 2014 in a different capacity regardless.
Kind regards,
Wynke Stulemeijer
FOSDEM stands team
This is a suboptimal way of handling it, because it will cause the
compiler to instantiate all GUIDs in all compilation units. When linking
only one will be selected for the executable, but still it increases the
size of all object files. If it is to allow a precompiled header, I
suggest adding an additional guid.c file, that only includes the guid
headers, not the precompiled header.
Timo
Am 24.12.2013 21:58, schrieb akhaldi(a)svn.reactos.org:
> Author: akhaldi
> Date: Tue Dec 24 20:58:27 2013
> New Revision: 61381
>
> URL: http://svn.reactos.org/svn/reactos?rev=61381&view=rev
> Log:
> [USBSTOR]
> * Define INITGUID in the main header.
> CORE-7716
>
> Modified:
> trunk/reactos/drivers/usb/usbstor/usbstor.c
> trunk/reactos/drivers/usb/usbstor/usbstor.h
>
> Modified: trunk/reactos/drivers/usb/usbstor/usbstor.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/usbstor/usbsto…
> ==============================================================================
> --- trunk/reactos/drivers/usb/usbstor/usbstor.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/usb/usbstor/usbstor.c [iso-8859-1] Tue Dec 24 20:58:27 2013
> @@ -10,7 +10,6 @@
>
> /* INCLUDES ******************************************************************/
>
> -#define INITGUID
> #include "usbstor.h"
>
> #define NDEBUG
>
> Modified: trunk/reactos/drivers/usb/usbstor/usbstor.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/usbstor/usbsto…
> ==============================================================================
> --- trunk/reactos/drivers/usb/usbstor/usbstor.h [iso-8859-1] (original)
> +++ trunk/reactos/drivers/usb/usbstor/usbstor.h [iso-8859-1] Tue Dec 24 20:58:27 2013
> @@ -1,5 +1,7 @@
>
> #pragma once
> +
> +#define INITGUID
>
> #include <ntddk.h>
> #include <usbdi.h>
>
>
>
Hi Eric,
I know this has been discussed before, but should we not just bite the bullet and replace this driver with the Microsoft driver.
The MS_LPL license allows it to be used in reactos, and it would certainly get rid of any unknowns and give us a reliable filesystem to work from.
http://code.msdn.microsoft.com/windowshardware/fastfat-File-System-Driver-1…
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of ekohl(a)svn.reactos.org
Sent: 29 November 2013 14:06
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.
Author: ekohl
Date: Fri Nov 29 14:05:43 2013
New Revision: 61145