[ros-kernel] ReactOS Roadmap

[KJK::Hyperion]

At 21.26 13/10/2003, you wrote:
>Please suggest:

I apologize in advance for my boring proposals, but I was born a Windows 
developer:

>· major milestones (6, 12 and 18 months away)

6 months: fully compatible cmd.exe. It's not just for ReactOS - it's for 
me. I'm tired of the stupid Microsoft command prompt that doesn't even 
support UNC paths. I need something to replace it *on Windows*. While our 
current version has proven to be "good enough" for most tasks, it has a 
so-and-so line editor, various glitches (like inconsistent handling of 
CTRL-C and CTRL-Break) and can't run the most complex batch scripts. In 
particular, I have problems running the Windows DDK environment scripts and 
"build" utility, and my automated backup scripts. I suspect it has 
something to do with our parsing algorithms - the original cmd.exe uses 
quite an odd one I fear ours doesn't duplicate exactly

12-18 months: getting rid of the CSRSS monstrosity for good. Screw the 
NT-compatible design: it's half-baked and ultimately broken. It's a memory 
hog, it's inflexible, it duplicates kernel data structures for no good 
reason, and it's the single worst bottleneck of process startup time. Its 
sole presence makes running user-mode processes and threads from kernel 
mode (piece of cake on UNIX) a living hell. Console handles not being valid 
handles is plain stupid, and introduces all sorts of limitations and 
baroque workarounds. If win32k.sys needs a process to map the shared data 
in read-write mode and run worker threads (the only good reason to have 
CSRSS still around), it can still fork the System process. CSRSS as a hard 
error handler is laughable: it just spams all desktops with the stupid 
stay-on-top message box we all know - even the MS-DOS hard error handler 
was friendlier than that. CSRSS as a debug proxy server is useless - 
LPC-based debugging is a thing of the past. Really, you can't do half-assed 
attempts at a microkernel: it's a microkernel or it's not, and all the land 
in the middle is covered in cow sh*t

>· minor milestones (minimum granularity of a month)

I want to be optimistic: one month for first rudiments of user-mode 
debugging. Two months for compatibility with the Windows XP native 
debugging API. Three months for running CDB and the Microsoft debugging 
core. Running WinDbg (or, god forbid, RedHat Insight) will then depend on 
the maturity of the common controls, common dialogs and/or the GUI in 
general (if user32.dll and gdi32.dll get better, I could run the Windows NT 
3.51 or 4 common controls during the "inter regnum", waiting for better 
times to come)

Finally, two years to hunt down and fix the thousand non-trivial bugs I 
have scattered throughout the kernel code, causing mysterious, random crashes