Hi all,
I think the *module* node needs two more attributes - *subsystem* and
*windows* - because at present module type and module subsystem are
merged in the *type* attribute and its values are a bit confusing to
me; also cui/gui information is hidden into value names.
I don't know the rbuild code and I can't therefore say if it is an easy
task splitting the logic behind the *type* attribute into tree
attributes whitout affecting the whole program logic.
A short rationale follows.
___
Valid values for the *type* attribute should be:
- library (static)
- hal
- driver
- program
- dll
Valid values for the *subsystem* attribute should be:
- none
- native
- windows
- posix
- os2
- vms
(default "windows"; "none" required for type "library"; "native"
required for types "hal", "driver")
Valid values for the *windows* attribute should be:
- no
- yes
(default "no"; "no" required for types "library", "hal", "driver")
___
Examples:
*ntdll.dll*
<module name="ntdll" type="dll" ...>
note that, at present, it is incorrectly described this way
<module name="ntdll" type="dll" subsystem="native" ...>
*ntoskrnl.exe*
<module name="ntoskrnl" type="program" subsystem="native" ...>
*atapi.sys*
<module name="atapi" type="driver" subsystem="native" ...>
--
:Emanuele Aliberti
There are pretty strong indications that the reactos.com box was cracked. It
took part in a DDoS attack. As a consequence, it was isolated from the
network. Unfortunately, I'm on vacation right now so I don't have physical
access to the box and am unable to fix/reinstall.
For the moment, I've moved the mailing lists to a backup box. I am not
moving the website, since it seems the attack was carried out via the
website (a vulnerability in one of the php script packages we use). I'll put
up a dummy page informing visitors.
Not sure how far along the release of 0.2.7 is, but I'd like to suggest to
put it off for at least another week, until I'm back and can sort things
out.
Apologies for the inconvenience, Ge van Geldorp.
Svn 16860 has fixed this problem
(drivers\net\ndis\ndis\io.c:824)(NdisMRegisterInterrupt) Called.
InterruptVector (0x9) InterruptLevel (0x9) SharedInterrupt (1)
InterruptMode (0x0)
(drivers\net\ndis\ndis\io.c:843)(NdisMRegisterInterrupt) Connecting to
interrupt vector (0x49) Affinity (0xFFFFFFFF).
(drivers\net\ndis\ndis\io.c:848)(NdisMRegisterInterrupt) Leaving. Status
(0x0).
I'll test again "ping" command with head
Regards
Gerard
Hello mr. Wilson and all others who is interested in USB mouse & keyboard.
USB mouse and keyboard is being worked on right now, and it will be ready before 0.3.0 and probably after 0.2.7. We are talking weeks not months. Then again, this will be the USB Key and mouse driver, so expect some time for it to mature. Keyboard drivers is probably to be released first because this driver doesn't need HID stack, then the mouse driver will be developed, but there is a need there if some one could find a USB mouse driver C source that doesn't use a HID stack it will be done a lot faster.
One interesting detail is that the development will be tested on XBox hardware which will make the XBox-port usable as a development platform.
Yours sincerely,
Jaix Bly
----Ursprungligt meddelande-----
From: Jonathan Wilson jonwil(a)tpgi.com.au
Date: Sat, 30 Jul 2005 02:21:02 +0200
To: ReactOS Development List ros-dev(a)reactos.com
Subject: [ros-dev] USB mouse support
> How far away is support for USB mice?
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
Hi all!
In Mastering, Win 2K Registry, Sybex books, Pages 282-285.
We need some registry fixup to save the wallpaper.
HKEY_USERS\.DEFAULT\Control Panel\Desktop,
entry Wallpaper, type REG_SZ and value: fully qualified bitmap image filename,
entry WallpaperStyle, type REG_SZ and value: 0,
entry TileWallpaper, type REG_SZ and value: 0, and on...
Same with Mastering, Win XP Registry, Sybex books, Pages 230-231, nothing changed.
Is there a problem with implementing some of these? What was the
show stopper?
Thanks,
James
gdalsnes(a)svn.reactos.com wrote:
> my 1st
>
>
> Added files:
> branches/hardons1stbranch/
>
> Updated files:
> branches/hardons1stbranch/kapi.h branches/hardons1stbranch/ntuser.h
>
> Deleted files:
> branches/hardons1stbranch/debug.h branches/hardons1stbranch/debug1.h
Hi Hardon.
Out of interest, what's the purpose of this branch?
(probably been discussed in IRC, but I missed it)
Thanks,
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
> -----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
