I really would like to see less "Fixed feature X" commit messages. Sometimes a features is "fixed" more than once in a short period
of time. Please specify what was changed in the commit message so others have a better chance of knowing what was actually changed
(without looking through the whole patch to figure it out). I'm not saying that simple typos or other trivial changes couldn't have
a "Fixed X" commit message, just that the non-trivial ones shouldn't.
Casper
In light of e.g.
http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html
I would like to suggest the following header ideas.
Currently MingW has:
1.A set of headers that contain a copy of part of the platform SDK
2.Some extra stuff (like that ntdll.h)
3.A set of headers that contain a copy of part of the windows DDK
4.Mabie again some extra stuff MS doesnt have (I dont know)
5.A set of headers that contain a copy of part of the visual C++ runtime
library
6.Some extra stuff (mainly bits required to deal with differences between
GCC and Visual C I think)
WINE has:
1.A set of headers that are supposed to contain a copy of part of the
platform SDK (although some things have been claimed to be wrong)
2.A set of headers that are supposed to contain a copy of part of the
visual C++ runtime library (although again there may be things that are wrong)
and 3.Extra definitions for stuff in both header sets microsoft doesnt
define in the platform SDK (e.g. internal bits, functions microsoft doesnt
document etc)
ReactOS has:
w32api (the ROS import of it)
include/ddk (the ReactOS version of the windows DDK)
include/wine (the WINE windows API headers)
include/msvcrt (the MSVCRT headers ROS uses to build and link with msvcrt)
include (various misc ReactOS specific headers)
What I suggest for ReactOS (and I think some of this is already being done)
is as follows:
grab any headers from include/* that are public DDK headers (if there are
any) and make sure they are all in include/ddk
grab everything from the current WINE headers MingW is missing. Check that
its all correct and stuff and add it to the ReactOS import of w32api. (if
anything is found to be wrong in the wine headers, it should be fixed)
grab anything from include itself and add to w32api as needed
Get permission to relicence the stuff and contribute back to the main
w32api tree.
grab contents of include/msvcrt on ReactOS plus include/msvcrt on WINE and
also mingw-runtime.
Create one set of header files from the 3 sets such that it matches the
microsoft headers as closely as possible.
Merge w32api DDK headers with ROS DDK headers and create one set that,
again, matches the MS headers.
For w32api/mingw-runtime, the suggestion is that they look at all the "new
stuff" generated by the merging of the 3 sets of msvcrt headers plus the
ROS/WINE/w32api merger plus the DDK merger and look at acccepting it.
For WINE, I suggest they start using the new "merged" headers if at all
possible.
Basicly, the idea is that mingw-runtime would become the "definitive" set
of msvcrt.dll headers out there and that ReactOS, MingW and WINE would
start using it for any case where you are talking to msvcrt.dll from the
public side.
both ROS and WINE would then have their own internal msvcrt headers as
necessary to build their msvcrt* builds
Then, w32api would become the "definitive" set of win32 api headers and
would contain as much of the Microsoft Platform SDK as people have legally
cloned. All userland components of ReactOS (as well as kernel-side bits
that need the stuff in the userland headers e.g. win32k.sys) would use
this. Be nice if WINE were to use this too but because of what WINE is and
how it is built/used, there may be reasons for the WINE team not to use
w32api as the build headers used to build WINE.
And, there would be one "definitive" set of DDK headers which would be good
enough for building ReactOS with. And for building any kernel-side stuff
WINE decides to add (e.g. that stuff to load the device drivers for
vaerious copy protection systems that was being worked on). And for anyone
using MingW and MingW GCC to build kernel-mode stuff.
Anything private or project specific would go into a set of private headers
as needed for the different projects and sub-sections (dlls etc) within them
Anything exported by microsoft but undocumented would go into a set of
"undocumented" headers (which could then be shared between ReactOS and WINE
since I dont think w32api would accept anything not documented in MSDN)
Just suggestions btw, if they are good, say so
If they are bad, say so (and say why)
If there are issues with my idea, say what they are.
Hi,
I've added the 'work item fix' to my source tree for testing. I'm not able
to boot reactos. Ros hangs somewhere in ndis:
...
(ldr/loader.c:319) Could not open module file:
\SystemRoot\system32\drivers\DLKRTS.SYS
(io/pnpmgr.c:1521) Initialization of service DLKRTS failed (Status c0000001)
DriverBase for \SystemRoot\system32\drivers\pci.sys: 9cd89000
Peripheral Component Interconnect Bus Driver
(io/create.c:90) Parent is a Directory which is neither a file type nor a
device type
(io/pnpmgr.c:1521) Initialization of service Ne2000 failed (Status c0000001)
DriverBase for scsiport.sys: 9cd93000
DriverBase for atapi.sys: 9cd9f000
DriverBase for aic78u2.sys: 9cdc9000
DriverBase for class2.sys: 9ce6b000
DriverBase for disk.sys: 9ce75000
DriverBase for vfatfs.sys: 9ce7e000
DriverBase for bootvid.sys: 9ce93000
DriverBase for ndis.sys: 9ceb4000
(ndis/main.c:52)(DriverEntry) Called.
(ke/main.c:710) CommandLine: multi(0)disk(0)rdisk(0)partition(3)\ReactOS
Without the fix, booting continues after that point with:
DriverBase for \SystemRoot\system32\drivers\DLKRTS.SYS: 9cf09000
(ndis/miniport.c:1090)(NdisInitializeWrapper) Called.
(ndis/miniport.c:1631)(NdisMRegisterMiniport) Called.
(ndis/miniport.c:1577)(NdisIAddDevice) LinkageKey:
Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0002\Linkage.
(ndis/miniport.c:1374)(NdisIStartAdapter) creating device \Device\DLKRTS1
(ndis/miniport.c:1394)(NdisIStartAdapter) opened device reg key
(ndis/miniport.c:1396)(NdisIStartAdapter) acquiring miniport block lock
...
- Hartmut
Hi,
I think I found a race condition in KQUEUE code, but I'm not sure my
solution is optimal. If no items are queued, KeRemoveQueue calls
KeWaitForSingleObject and then after it finishes it acquires dispatcher
lock and removes a list item. The problem arises when someone calls
KeRemoveQueue just after the KeWaitForSingleObject call finishes and
before the dispatcher lock is acquired. In this case he can remove the
last item in the list and this will cause the first KeRemoveQueue (the
one that waited) to return garbage. Can anybody think of better solution
than the attached patch?
Regards,
Filip
Index: ntoskrnl/ke/queue.c
===================================================================
RCS file: /CVS/ReactOS/reactos/ntoskrnl/ke/queue.c,v
retrieving revision 1.11
diff -u -r1.11 queue.c
--- ntoskrnl/ke/queue.c 15 Aug 2004 16:39:05 -0000 1.11
+++ ntoskrnl/ke/queue.c 21 Nov 2004 00:39:52 -0000
@@ -159,27 +159,38 @@
return ListEntry;
}
- //need to wait for it...
- KeReleaseDispatcherDatabaseLock (OldIrql);
-
- Status = KeWaitForSingleObject(Queue,
- WrQueue,
- WaitMode,
- TRUE,//Alertable,
- Timeout);
-
- if (Status == STATUS_TIMEOUT || Status == STATUS_USER_APC)
- {
- return (PVOID)Status;
- }
- else
+ for (;;)
{
- OldIrql = KeAcquireDispatcherDatabaseLock ();
- ListEntry = RemoveHeadList(&Queue->EntryListHead);
+ //need to wait for it...
KeReleaseDispatcherDatabaseLock (OldIrql);
- return ListEntry;
- }
+ Status = KeWaitForSingleObject(Queue,
+ WrQueue,
+ WaitMode,
+ TRUE,//Alertable,
+ Timeout);
+
+ if (Status == STATUS_TIMEOUT || Status == STATUS_USER_APC)
+ {
+ return (PVOID)Status;
+ }
+ else
+ {
+ OldIrql = KeAcquireDispatcherDatabaseLock ();
+
+ /*
+ * Prevent a race condition. If someone calls KeRemoveQueue
+ * just after we end up waiting and before acquiring the spin
+ * lock he can get the last item in the list...
+ */
+ if (IsListEmpty(&Queue->EntryListHead))
+ continue;
+
+ ListEntry = RemoveHeadList(&Queue->EntryListHead);
+ KeReleaseDispatcherDatabaseLock (OldIrql);
+ return ListEntry;
+ }
+ }
}
These are a big mystery to me. I'd like to document how to create them, but I need to know how to create them first. Please send me
any information you have on them.
Casper
I'm hoping to get putty working to use as another test case for the network
code. I'm running into problems right now, however and could really use
a hand.
There are two versions of putty in here, built with symbols as well as a
diff against the original sources and a mingw-able makefile named
makefile.mgw
I haven't tried the mingw makefile on windows but it shouldn't take too
much effort.
putty-noshow differs from the release putty only in that it contains
debug messages and symbols. The putty dialog is created and the caret
timer even fires, but the window is never shown. w3seek thinks that
the dialog functions in user32 and win32k are correct, but the dialog
shows on windows and wine so something is wrong.
If I add a ShowWindow as in putty-show, the dialog shows, so the
problem is clearly in reactos.
I'm seeing some random crashes as well accessing the registry that
will be the subject of another mail.
my putty musings: http://64.81.145.152/~arty/putty.zip
Putty page: http://www.chiark.greenend.org.uk/~sgtatham/putty/
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
Does anyone care if I merge the duplicate headers from
reactos/include/wine in to the headers in the reactos/w32api/include
folder? There are a few headers we will want to keep in
reactos/include/wine but now that we have our own copy of the w32api we
dont need most of these headers that do the #include_next thing.
Thanks
Steven
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
I have set up an account at CafePress, and would like
to make some ReactOS merchanise, for advertisment
purposes. I do not intend on adding a retail markup
to the base price of the items in question- the prices
will be solely the price mandated by CafePress for
fabrication and shipment. (this means I make nothing)
Some of the items that can be made, include Mugs,
buttons, mousepads, T-shirts, hoodies... ...Thongs...
and other misc. items.
I think it could have utility for us as a project, on
occasions where we are promoting our project-- Things
like "ReactOS Developer" buttons for our booth
sitters, etc...
I would like a "Yeah"/"Nay" vote, and then I may
require a written letter of permission allowing me to
use the logo. (The letter is required by the CafePress
legal terms of service contract)
Please let me know what you think of the idea.
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com