I was wondering what software was being run on the ReactOS machine. I know
that it is a version of linux and I guess php and mysql. Are there any
others?
Hi,
the date of the branch for the 0.2.7-release is fastly approaching.
I dated it for Monday, 11.06. So there's still over one week ahead. I
please you to stop implementing new features but and finish bigger
reorganizations in the code. Keep the checked in code compileable.
If you have issues concerning the date of the branch, post a message.
More or less for my own (but also from comments on the ml) I decided to
do a just normal release with normal names. So there will be no "network
preview release" or such kind.
Whats happening with this?
It seems to have died a death again.
Can we appoint some more people to the web team as there have been some
great ideas put forward, but nobody seems to be acting on them.
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
ekohl(a)svn.reactos.com wrote:
>Add architecture-specific headers and move I386-specific definitions into them.
>
>
>
Thanks a lot Eric.
I did some research on another FIXME that is actually related to your
PnP work, which you might want to take a look at. You will notice that
DEVICE_NODE has 2 non-NT members. I saw that you had some previous
patches concerning this structure that removed some of the ROS-Only
fields, and I guess you might want to get rid of the two ones remaning.
The first is BusTypeGuid. The correct way it should be handled is
through a private array of GUIDs, which is indexed according
DeviceNode.ChildBusTypeIndex.
When querying, you just return the GUID in
IopXxxxx[DeviceNode.ChildBusTypeIndex], and when creating a bus type
guid, you just write the index there. I hope that's clear enough.
The second is "Address". That field is actually already present in the
DDK-documented DEVICE_CAPABILITIES structure. Therefore, when queried
for it, simply send an IRP_MJ_QUERY_CAPABILITIES (or whatever the name
is) to DeviceNode->PhysicalDeviceObject, and return the
DeviceCapabilities.Address.
That should be less then 20 lines of code to change, but I don't want to
break any PnP features since they aren't my speciality..
Best regards,
Alex Ionescu
Shouldn't that be 'of reg key'? ;)
On 7/4/05, gdalsnes(a)svn.reactos.com <gdalsnes(a)svn.reactos.com> wrote:
> fix premature close og reg key
>
>
> Updated files:
> trunk/reactos/lib/setupapi/devinst.c
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
>
--
"I had a handle on life, but then it broke"
ekohl(a)svn.reactos.com wrote:
>- Move definitions from ntpnp.h into NDK and DDK
>- Remove ntpnp.h
>
>
>Updated files:
>trunk/reactos/include/ndk/zwfuncs.h
>trunk/reactos/include/ndk/zwtypes.h
>trunk/reactos/lib/wdmguid/wdmguid.c
>trunk/reactos/ntoskrnl/include/ntoskrnl.h
>trunk/reactos/ntoskrnl/io/plugplay.c
>trunk/reactos/services/umpnpmgr/umpnpmgr.c
>trunk/reactos/w32api/include/ddk/wdmguid.h
>
>Deleted files:
>trunk/reactos/include/ddk/ntpnp.h
>
Hi,
Heh, you beat me to it! I asked Filip if it was OK to do this and was
going to do it myself, thanks for thinking foward. I just have two comments:
- I think the GUIDs are undocumented, while wdmguid.h is a DDK
header. Therefore, adding them there breaks MS DDK compatibility, since
we'll get undefined errors if we build with it. Sorry to nitpick about
compatibility again.
- To keep size small and to stick with the current way the NDK has
been made, I would prefer if there were no coments in it that describe
or document structures. The comments should go on top of the actual APIs
in the source files. Sorry for nitpicking again ;-).
Best regards,
Alex Ionescu
mf(a)svn.reactos.com wrote:
> prepare for WINE UNICODE patch
>
>
> Updated files:
> trunk/reactos/subsys/system/winefile/winefile.c
> trunk/reactos/subsys/system/winefile/winefile.h
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
>
This change broke compiling:
subsys\system\winefile\winefile.c: In function `path_from_pidlA':
subsys\system\winefile\winefile.c:706: warning: implicit declaration of
function
`free_strret'
subsys\system\winefile\winefile.c: At top level:
subsys\system\winefile\winefile.c:716: error: redefinition of 'wcscpyn'
subsys\system\winefile\winefile.c:671: error: previous definition of
'wcscpyn' w
as here
subsys\system\winefile\winefile.c:1096:2: #endif without #if
subsys\system\winefile\winefile.c: In function `CheckForFileInfo':
subsys\system\winefile\winefile.c:1821: warning: passing arg 1 of
`GetFileVersio
nInfoSizeW' discards qualifiers from pointer target type
subsys\system\winefile\winefile.c:1826: warning: passing arg 1 of
`GetFileVersio
nInfoW' discards qualifiers from pointer target type
subsys\system\winefile\winefile.c: At top level:
subsys\system\winefile\winefile.c:671: warning: 'wcscpyn' defined but
not used
subsys\system\winefile\winefile.c:698: warning: 'path_from_pidlA'
defined but no
t used
mingw32-make[1]: *** [obj-i386\subsys\system\winefile\winefile.o] Error 1