Since I am not deep in developement and thus have no feeling about the
curent state, I ask you:
How about the next Release build to put on sf.net?
Is the new build system running well, already?
Do we have the features for a 0.3?
Will we want to do another intermediate?
Why not release every other month... it's not nonsensical.
It's agile.
If no big changes: 0.2.6.1
If big bugfixes: 0.2.7
If important features: 0.3
And so on.
Hi all,
this is just a little note for those nice guys that are working hard in
cleaning the headers.
LPC proper and related names are divided in three groups:
- PORT_xxx or xxx_PORT (API/struct/macro for LPC port object handling;
end user API);
- LPC_xxx (API/struct/macro used in other executive subsystems or drivers);
- LPCP_xxx (executive mode only private LPC facility memory object names).
(I do not guarantee it is 100% correct; some subsets may overlap).
--
:Emanuele Aliberti
Hello,
I am just subscribed, I do not know if I will contribute or not, need to browse the code and the website for longer to see. Now the question:
Where is if any documentation to the ReactOS booting process in maximum details?
The area of my interest is to try to create Win32 console environement build from ReactOS. That is no windows, no graphics. Only the command line, much like linux or freebsd after the boot.
My experience with ReactOS has never been any good. I guess few years ago when I first heared of ReactOS, I tried to set it up, and got no luck. I keep trying every six month, and few days ago I downloaded the .iso and - oops, no luck again, it now complains about "cabinet not found", dude, this is an installation CD! So I guess I have to go down to source and keep the stuff under control. And the first thing I want to know is the boot process in details.
If anyone here is afraid of anonyms my name is Yakov Sudeikin I live in Siberia. I like the idea of ReactOS and I just unsubscribed from other developer's mailing lists ([dev-freepascal] and [dev-shareware] got me bored finally) and it looks I cannot simply live without being a part of [dev-something].
Yash
Hi.
Due to work on the power at the Danish Internet eXchange (DIX) from 2300 - 2400 GMT+1 (in ~45 minutes) there may be short
disturbances in the traffic to svn.reactos.com during that period.
Sorry for the inconvenience,
Casper
> Hi Martin,
> Thanks for this info. It looks like this might work. How do I contact
> Eric Kohl?
>
> Thanks,
> James
This is his email address: Eric Kohl <eric.kohl(a)t-online.de>
Perhaps you should also send a note to the ReactOS Development List.
Regards,
Martin
> On Tue, 2005-06-21 at 17:57 +0200, Martin Fuchs wrote:
> > Hi James,
> >
> > > Last night Martin Fuchs suggested that we look into using ReactOS's
> > > registry format in order to be compatible with Windows registry
> > > databases. I have the latest release of ReactOS running on QEMU on my
> > > box, so I checked it out. Basically, they're using the same regedit
> > > program from Wine, missing find command and all (Which I too feel is a
> > > pain in the neck).
> >
> > A bunch of dlls and applications are synced between Wine and ROS from
> > time to time, also including regedit. What about implemting the
> > missing find functionality at your own to bring both projects a little
> > foreward? ;-)
> >
> >
> > > I looked at the config stuff, and I found what looked
> > > like some binary database files for each of the main registry sections.
> > > Unfortunately, there's no documentation at all on any of this on their
> > > website.
> >
> > I can forward you a mail from Steven Edwards to bring a bit light into
> > this issue:
> >
> > S> I think ReactOS's registry is binary compatible with NT4. It and
> > the windows 2000 format was
> > S> documented/reversed for samba and the linux ntchpwd bootdisk
> > projects. If I remeber right Eric
> > S> Kohl offered to release some of his work to Wine for the binary
> > format so you might want to ping
> > S> him about the implementation details.
> >
> > So Eric Kohl would be the right man to ask about the internals of NT's
> > registry format.
> >
> > > If we decide to go this route, we may be in for a hell of a lot
> > > of work. But, I do agree with all of your points. I think the current
> > > system could use some improvement, especially in the area of searching.
> > > Let me know what you think of all this.
> >
> >
> > Regards,
> >
> > Martin
hyperion(a)svn.reactos.com wrote:
>fixes for Visual C++:
>
>
You should _really_ merge most of these (the non-hack ones) into trunk
ASAP. If not, what has a large risk of happening is that:
1) Too many changes happen in your branch which are purely related to
MSVC compilation and not to UMODE, bugs happen and we don't know why anymore
2) If you take large breaks from the branch, changes rot away and
eventually never get included.
So please, I urge you to commit most of these fixes into trunk and check
that they remain GCC compatible... for your own good too. These kinds of
branches can be a pain.
Best regards,
Alex Ionescu
ion(a)svn.reactos.com wrote:
> Syssetup has fallen to the dark side
ion(a)svn.reactos.com wrote:
> jingle bells batman smells, robin laid an egg (build rosrtl with NDK)
Thanks, very informative, definitely improves the credibility of the
project...
Thomas
Hey all I was wondering what the networking status was. I am planning on
writing a small tcp/ip service for reactos to use personally. Thanks for the
update.
Hi,
with the current svn, I get memory loads from kernel32, which are
greater than 100:
(KERNEL32:lib\kernel32\mem\global.c:412) Memory Load: 659
- Hartmut