Yesterday reactos.com crashed. Unfortunately, I was unable to go onsite to
fix the problem yesterday. This morning, I rebooted the box and everything
seems to be up and running again.
It seems some mail sent to @reactos.com yesterday may have been dropped.
Ge van Geldorp.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Christof Petig wrote:
|
| This limitation really hurts if you do not plan to use ROS exclusively
| on that computer (e.g. if you do not want to throw XP away completely or
| you already use a first primary partition for linux).
|
ROS and XP can share the same partition. It just cannot be NTFS. You
can always move partitions around.
And yes, while the limitation "hurts," that's a workaround that you can
use. Short of editing the source code, I'm not sure if there's much
that can be done. I'll cc: this to the dev list and ask if the
limitation still is there, but I personally don't see anything about it
having changed. Consider that ROS is still in "early" stages of
use/release. 0.3 hasn't even been released yet. I am sure that when
the partition/fs code is better able to deal with multiple partition
setups, it will all work as it would be anticipated it would.
- Mike
- --
Michael B. Trausch <fd0man(a)gmail.com>
Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com
Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647
===================================================================
Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCbiTLPXInbkqM7nwRAwl+AJ9U7aJ/HjCf72KuEkj4SjcM0wrpXgCfb6bs
k9UbhobagYdusxcub9csK7U=
=w/H8
-----END PGP SIGNATURE-----
Hi,
If you need it here it is. Only explorer.exe does not build. The rest will compile if you shutup
-Werror. For the C++ code that I have compared vs 3.4.1 its almost 2x faster.
Thanks
Steven
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Vote results (Which kernel you prefer to see as base of osFree kernel?):
What
Percentage
Votes
L4
30.6 %
609
Linux
13.4 %
267
Mach
7.2 %
144
ReactOS
43.9 %
874
Other
4.4 %
87
This poll is taken from http://www.osfree.org/index.php
Hi!
I programmed the ReactOS Package Manager - Online Website (started
yesterday). It provide the online database (xml database) for the ReactOS
Package Manager (exe) (svn: /trunk/rosapps/packmgr).
Some important main function of the page already work. The page (written in
php with mysql database) provide the database files (static xml files) for
the client (packmgr.exe).
So the Package Manager only download some static xml files (spare server
resources).
Url: http://frik85.fr.funpic.de/packmgr/ (for test purposes)
Test the package manager (in Win32) with the new online database:
* Compile the packmgr files (gui-app + dll)
* change the server in option.xml to:
<options>
<source>http://frik85.fr.funpic.de/packmgr/db/</source>
</options>
* start the gui application (packmgr.exe)
Wiki-Page: http://reactos.com/wiki/index.php/ReactOS_Package_Manager
Klemens Friedl
--
+++ GMX - Die erste Adresse f�r Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail
Hi,
I've found some other problems. For the serial debug, the default
baudrate is set to 19200 baud and the baudrate option has no effect. Two
debug port options like "/DEBUGPORT=BOCHS /DEBUGPORT=COM2" switches my
pc off. The on/off switch has no effect after this. I must remove/insert
the power plug to boot the pc again. I use this option for the bootcd.
The previous debug implementation has enabled the bochs and serial debug
at boot phase 0 and all other debug variants at boot phase 1. Currently
KdInitSystem(0, ..) is called twice. The first call is in _main and the
second in ExpInitializeExecutive.
- Hartmut
Hi,
your changes breaks compiling with DBG := 1 and KDBG := 0.
- Hartmut
ion(a)svn.reactos.com wrote:
>KD System Rewrite:
>
> - Totally dynamic based on the principle of Native Providers built-in the Kernel (like Screen,
> FileLog and Serial) and a pluggable Wrapper which is optionally compiled (Bochs, GDB)
> - Nothing changed in KDBG, except for that its settings (KDSERIAL/KDNOECHO) are now stored in
> KdbDebugState instead.
> - Wrappers are currently built uncondtionally. With rbuild, I'll make them easily removable.
> - Debug Log code simplified greatly, sped up and now supports printing even the first boot messages,
> which wasn't supported before.
> - Removed most of KDBG compile-time settings, ones which are needed are in include/dbg as macros now.
> - Left in some kdbg init code and break code, but it could be made to be used as a 'wrapper' for those
> functions. I will do it later.
> - Made a hack for KdpEnterDebuggerException..it seems to be called differently and at different times
> for GDB vs KDBG and I couldn't unite them.
> - KdpServiceDispatcher now does both the documented and ros-internal debug functions and will eventually
> be called through INT2D from keyboard.sys instead of as an API.
>
>All in all, this patch makes KD separated from KDBG and creates a pluggable architecture for creating future wrappers that don't require changing tons of code in the future. It improves the debug
>log by printing even the earliest debug messages to it and it removes many of the manual ifdef(KDBG) but making them automatic though a single macro file. It makes extra debugging functionality optional and it
>allows removal of a private API from our exports.
>
>
>Added files:
>trunk/reactos/ntoskrnl/include/internal/kdbochs.h
>trunk/reactos/ntoskrnl/include/internal/kdgdb.h
>trunk/reactos/ntoskrnl/kd/kdinit.c
>trunk/reactos/ntoskrnl/kd/kdio.c
>trunk/reactos/ntoskrnl/kd/kdmain.c
>trunk/reactos/ntoskrnl/kd/wrappers/
>trunk/reactos/ntoskrnl/kd/wrappers/bochs.c
>trunk/reactos/ntoskrnl/kd/wrappers/gdbstub.c
>
>Updated files:
>trunk/reactos/drivers/input/keyboard/keyboard.c
>trunk/reactos/include/ddk/kefuncs.h
>trunk/reactos/ntoskrnl/Makefile
>trunk/reactos/ntoskrnl/ex/init.c
>trunk/reactos/ntoskrnl/include/internal/dbg.h
>trunk/reactos/ntoskrnl/include/internal/kd.h
>trunk/reactos/ntoskrnl/include/internal/kdb.h
>trunk/reactos/ntoskrnl/include/internal/ke.h
>trunk/reactos/ntoskrnl/include/internal/module.h
>trunk/reactos/ntoskrnl/include/ntoskrnl.h
>trunk/reactos/ntoskrnl/io/iomgr.c
>trunk/reactos/ntoskrnl/io/pnpreport.c
>trunk/reactos/ntoskrnl/kd/service.c
>trunk/reactos/ntoskrnl/kdbg/kdb.c
>trunk/reactos/ntoskrnl/kdbg/kdb_cli.c
>trunk/reactos/ntoskrnl/kdbg/kdb_serial.c
>trunk/reactos/ntoskrnl/kdbg/kdb_symbols.c
>trunk/reactos/ntoskrnl/ke/bug.c
>trunk/reactos/ntoskrnl/ke/catch.c
>trunk/reactos/ntoskrnl/ke/i386/exp.c
>trunk/reactos/ntoskrnl/ke/i386/irq.c
>trunk/reactos/ntoskrnl/ke/i386/syscall.S
>trunk/reactos/ntoskrnl/ldr/loader.c
>trunk/reactos/ntoskrnl/mm/RPoolMgr.h
>trunk/reactos/ntoskrnl/mm/marea.c
>trunk/reactos/ntoskrnl/ntoskrnl.def
>
>Deleted files:
>trunk/reactos/ntoskrnl/kd/dlog.c
>trunk/reactos/ntoskrnl/kd/gdbstub.c
>trunk/reactos/ntoskrnl/kd/kdebug.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
> From: ion(a)svn.reactos.com
>
> Add GDB = 1 to makefile to compile-in the GDB Wrapper. These
> options will be better manged with rbuild
Any reason the inclusion of the GDB stub can't be keyed on the existing
"DBG" var? I feel (pretty strongly) we should minimize the number of
compile-time configs.
Gé van Geldorp.
> -----Original Message-----
> From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of
> ion(a)svn.reactos.com
> Sent: 25. april 2005 17:20
> To: ros-svn(a)reactos.com
> Subject: [ros-svn] [ion] 14801: Add GDB = 1 to makefile to compile-in theGDB Wrapper. These options
> will be better manged with rbuild
>
> Add GDB = 1 to makefile to compile-in the GDB Wrapper. These options will be better manged with
> rbuild
>
>
> Updated files:
> trunk/reactos/config
Experience has told us that with compile-time options come more compilation errors (and we have enough of those). Please compile it
in always and make it a run-time option instead to avoid this. The extra bytes are well spent.
Casper
rbuild has one bug ( that we're aware of ) blocking it from being ready
to go live.
Basically, both bootcd and livecd are halting with a
"inaccessible_boot_device" after blue.sys.
Would anybody be willing to look at it and help us figure out what we're
doing wrong when generating the ISOs?
Also, being this close, would everybody who cares please check out the
rbuild branch for feedback before we go live?
Here's the branch url: svn://svn.reactos.com/branches/xmlbuildsystem/reactos
Thanks