> -----Original Message-----
> From: Richard [mailto:eek2121@comcast.net]
> Sent: Friday, July 29, 2005 12:18 AM
> To: 'ReactOS Development List'
> Subject: Re: [ros-dev] RE: [ros-svn] [gdalsnes] 16793: my 1st
>
> Then where is this effort? Why is one developer wandering off on his
> own? How about setting a 'win32k rewrite' as a goal for 0.4? That is,
> if 0.3 ever makes it out the door...
>
> Honestly, i think that devs should work towards the feature set we
> planned for 0.3, however that is just me. Granted, there is no money
> involved in this project, but not setting goals and randomly doing
> rewrites is the fast way to code burnout, boredom, and lost interest.
> Drowning yourself in an impossibly large project is nuts.
>
> Richard
Not meeting 0.3 is largely my fault. I don't even know when I'll be
able to return to writing on it in a consistent way, given my new job :-(.
I've had several offers from others to write on it but it seems that most
people either aren't very interested in what remains, or don't feel
confident about working on kernel code. The remaining kernel tasks
don't actually involve much know-how about the kernel, and my components
are designed to be easy to understand (with minimal concurrency).
Only three things are needed to meet the 0.3 goal:
1) retest apps on the 0.3 list and fix regressions
2) finish the net cpl and possibly fix bugs in npfs that make CallNamedPipe
bugcheck
3) (big) finish needed stuff for mozilla compatibility
There are a lot of generic tasks in net that need doing, and could
really be done by anybody. They affect the kernel but won't use very
much specific kernel code:
1) Plumb remaining ioctls into kernel land (afd/info.c,tcpip/*info.c)
- Keepalive
- Nagle
- TTL (datagram and tcp)
- Verify behavior of nonblocking sockets
- send/rcv buf
2) Plumb ARP cache requests (tcpip/iinfo.c,network/neighbor.c)
3) Put together a test matrix for socket end conditions (when I get my
stuff from chicago next saturday, I'll be able to pass on my test
apps and notes), and emulate winsock properly.
4) Finish the NTSTATUS -> winsock error conversion and use it everywhere
5) Finish off errno -> NTSTATUS conversion in tcp.c
6) Finish any kernel-related IOCTL changes
7) Write a test tool and verify WSAEnumNetworkEvents
8) Do some refactoring in afd/select.c to make it easier to understand
Hard kernely tasks:
1) Fix IRP cancellation in tcpip
2) Verify CLOSE/CLEANUP in afd and tcpip
3) Better buffer management in afd
4) Fix use of TDI_TRANSPORT_ADDRESS vs TA_ADDRESS and verify
correctness based on osr docs
5) Test out our AFD and TCPIP on real windows with kd
6) Replace recursive mutex
Why not just remove the code in #if 0/#endif? It serves no purpose.
________________________________________
From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of ea(a)svn.reactos.com
Sent: 29. juli 2005 12:05
To: ros-diffs(a)reactos.com
Subject: [ros-diffs] [ea] 16854: Various fixex to make HEAD compile.
Various fixex to make HEAD compile.
I hope I did break nothing.
Modified: trunk/reactos/hal/halx86/generic/processor.c
Modified: trunk/reactos/lib/advapi32/sec/trustee.c
Modified: trunk/reactos/lib/advapi32/service/scm.c
Modified: trunk/reactos/subsys/csrss/win32csr/desktopbg.c
Modified: trunk/reactos/subsys/ntvdm/ntvdm.c
Modified: trunk/reactos/subsys/smss/client.c
Modified: trunk/reactos/subsys/system/setup/setup.c
Modified: trunk/reactos/subsys/system/winlogon/setup.c
Modified: trunk/reactos/subsys/win32k/ntuser/keyboard.c
________________________________________
Modified: trunk/reactos/hal/halx86/generic/processor.c
--- trunk/reactos/hal/halx86/generic/processor.c 2005-07-29 09:51:08 UTC (rev 16853)
+++ trunk/reactos/hal/halx86/generic/processor.c 2005-07-29 10:04:38 UTC (rev 16854)
@@ -39,7 +39,9 @@
HalStartNextProcessor(ULONG Unknown1,
ULONG ProcessorStack)
{
+#if 0
DPRINT("HalStartNextProcessor(%x %x)\n", ProcessorNumber, ProcessorStack);
+#endif
return TRUE;
}
Wouldn't it be good to forward web-users to http://reactosde.re.funpic.de ?
or at least put a link for those wanting to go on with something?
Yours sincerely,
Jaix Bly
Hi.
I'm upgrading Subversion on svn.reactos.com to version 1.2.1
to correct some memory leaks in svnserve. Subversion 1.2.x
also brings us:
Faster access to old revisions. svn blame, svn checkout,
svn update, svn diff, svn merge will be faster.
Locking. If you have an 1.2.x client you can lock files and
directories. This is mostly useful for binaries so it's
possibly not something we will use much.
For faster access to old revisions, a "dump and load" of the
repository is needed so the repository will be unavailable
for a few hours today.
Casper
Hi,
It seems that the problem regarding Ged's RTL network card is related to
patch 15402:
http://svn.reactos.com/viewcvs?view=rev&rev=15402.
Is it possible that the card is incorrectly (or not in the same way we
are expecting) telling us its resource data? Or that somethign has been
overlooked? Ged has done a terrible deal of network testing for us but
he's been unable to work since his network card couldn't even ping
anymore. I've helped him find the regression and I hope someone more
experienced in PnP can help him out... at least we know what patch did it.
Best regards,
Alex Ionescu