Which are current installation methods for ReactOS?
so far only an ISO it seems, which for non-emulators requires to
write/burn a disk,
turn it into a drive that can read burned media (not all cdrom drives
can do this),
and also requires El-Torito support from the system BIOS.
That last part might be worked around, if not supported by the system,
by using Smart Boot Manager,
which provides its own Eltorito stack.
Questions:
-why do an installed ROS, a ROS LiveCD and a ROS installCD all have a
directory (root_of_drive)\REACTOS ?
This makes it complex to have all 3 on 1 drive.
WindowsXP/BartPE can use C:\WINDOWS (installed), C:\I386 (setup) ,
C:\MINIPE (LiveCD) for example
-Is it possible to copy the contents of the install CD to a 2nd fat
partition, and setup FreeLDR (on diskette for example)
to boot that directory?
some line like:
multi(0)disk(0)rdisk(0)\partition(2)\ReactOS="Install ReactOS from
D:\REACTOS to C:\REACTOS"
if the ReactOS install CD used any other directory name than a hardcoded
'\REACTOS', then 1 partition would have been enough.
multi(0)disk(0)rdisk(0)\partition(1)\ROSsetup="Install ReactOS from
C:\ROSSETUP to C:\REACTOS"
-How do I obtain FreeLDR, other than "installing ReactOS in an emulator
first and selecting to install bootloader to A:" ?
Can't find the old DOS INSTALL.COM/EXE file along with both FREELDR.SYS/INI
-Does installing ReactOS from harddisk actually work?
At least it prevents users having to provide controller/cdrom drivers
(be it DOS or Win32 drivers).
-Anyone tried ROS LiveCD + QEMU (without configuring a harddisk!) ?
doesn't bootup, might be a QEMU issue.
Vmware + LiveCD works, though C was assigned which isn't nice in case
you decide to partition in a GUI Diskmanagement
subsystem.
In best case, FreeLDR or a minisetup would be able to handle a (zipped)
ISO by extracting the files inside it
to a temporary location, and start setup from there.
Is there any premade FreeLDR diskette image available somewhere?
Bernd
gdalsnes(a)svn.reactos.com wrote:
>-reorder InsertXscendingOrder macro argument order and update uses
>-start to macrofy list enums in ntoskrnl using LIST_FOR_EACH macros
>-use IsListEmpty some places instead of manual coding
>-profile.c:KeStartProfile() zero correct buffer in (and not the NULL ptr;-)
>-improve LIST_FOR_EACH macros so that the iterator is set to NULL at end of enum
>-kthread.c:KiServiceCheck() set the shadowtable before calling the win32k proc/thread init funcs
>-apc.c:KiInsertQueueApc() insert special apcs in correct fifo order
>-apc.c:KeFlushQueueApc() simplify
>-timer.c:KiExpireTimers() calling RemoveEntryList on a possibly empty list is not ok
>
>
>Updated files:
>trunk/reactos/include/reactos/helper.h
>trunk/reactos/ntoskrnl/io/device.c
>trunk/reactos/ntoskrnl/io/driver.c
>trunk/reactos/ntoskrnl/io/file.c
>trunk/reactos/ntoskrnl/io/fs.c
>trunk/reactos/ntoskrnl/io/irp.c
>trunk/reactos/ntoskrnl/io/pnpnotify.c
>trunk/reactos/ntoskrnl/io/pnproot.c
>trunk/reactos/ntoskrnl/ke/apc.c
>trunk/reactos/ntoskrnl/ke/bug.c
>trunk/reactos/ntoskrnl/ke/kqueue.c
>trunk/reactos/ntoskrnl/ke/kthread.c
>trunk/reactos/ntoskrnl/ke/profile.c
>trunk/reactos/ntoskrnl/ke/queue.c
>trunk/reactos/ntoskrnl/ke/timer.c
>trunk/reactos/subsys/system/usetup/partlist.c
>trunk/reactos/subsys/win32k/ntuser/class.c
>
>__________________________
>
Hi,
I'm going to have to voice my extreme outcry against this patch. It is
replacing clear and easily debuggable code by non-standard macros which
are impossible to debug. It is also going to create problems when people
which are not used to them (such as myself):
1) Have no idea what some LIST_FOR_EACH_SAFE thing is doing vs
LIST_FOR_EACH vs InsertListLifoSafeMaybeLoopOrWhoKnowsWhat
2) Will never code using these macros, and thus the source will become
full of both methods, which is totally ugly.
Sometimes, especially in kernel code, it's much better to have an
expanded logic then to use a macro. I wrote a great majority of the code
that has just been, imho, pollutted with these macros, and I don't
appreciate for someone to barge in and change my code for some macro
that I don't understand, nor wish to, because it only causes problems. I
take great care of the code I write and "own" it (in the programming
term) so that if a bug in it arises, I can quickly identify it and be
held responsible for it. The addition of these macros hinders that effort.
I don't mind someone using them inside his or her own code. I just mind
their usage in ntoskrnl, and even more so when it overwrites the clean,
clear code that I've written and am used to debugging.
Best regards,
Alex Ionescu
Would it be possible to post IRC logs in html format on the website
for searching and information?
Rick Langschultz
rlangschultz(a)cox.net (Home)
rlangschultz(a)ellemaespa.com (Work)
rlangschultz(a)email.uophx.edu (School)
Hello,
The web teams has requested that we purchase a software package to handle our forum discussion on
the website. The purchase cost is $160
http://www.vbulletin.com/
We have about $90 in paypal donated for misc needs and this seems like a good buy if we really
need it. After our hack of the website this may be a good thing. I would like to have a vote up or
down about the purchase. If the majority of the project supports this then once we reach the
required amount we will purchase.
Please reply to me in private, the foundation or general lists only. Do not follow this thread on
ros-dev.
Thanks
Steven
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Royce Mitchell III wrote:
> Rick Langschultz wrote:
>
> > Would it be possible to post IRC logs in html format on the website
> > for searching and information?
> > Rick Langschultz
>
> I feel very strongly this would be a bad thing.
I was just thinking the same thing.
Anyway, #reactos is mainly for arguing, talking garbage and rejoicing
cheesecake ..... what can anyone possibly gain from logging that ;)
************************************************************************
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
What are the relevent ReactOS API calls for building a dynamicly
loadable subsystem?
I'm asking this because I can't find the API documentation on the
website. (I looks more like the documentation is not yet completed.)
Other questions relevent to this:
How do I register a new executible file format? I.E. coff.
How do I register a new interrupt vector(s).
What are the API to control v86 prosses?
If y'all want to know what subsystem I want to write, it is DOS. This is
because I'm more familar with programing in DOS.
Thursday afternoon (UTC) the website will be unavailable for some time.
We're going to make the switch to the new website design then. At the same
time, we're moving to www.reactos.org as the primary name for the website,
with www.reactos.com being an alias (you'll be redirected automatically to
www.reactos.org if you use the old name).
The mailing lists are also going to be moved from reactos.com to
reactos.org, so if you have filtering in place please take this into
account.
Many thanks to Michael Wirth and especially Klemens Friedl who put a lot of
effort in the new site.
Gé van Geldorp.
gdalsnes(a)svn.reactos.com wrote:
> *Modified: trunk/reactos/include/reactos/helper.h*
>
>--- trunk/reactos/include/reactos/helper.h 2005-09-26 22:06:31 UTC (rev 18112)
>+++ trunk/reactos/include/reactos/helper.h 2005-09-26 22:57:48 UTC (rev 18113)
>@@ -18,17 +18,21 @@
>
> #define EXPORTED __declspec(dllexport)
> #define IMPORTED __declspec(dllimport)
>
>
>
>-/* iterate through the list using a list entry */
>
>
>+/* iterate through the list using a list entry.
>+ * elem is set to NULL if the list is run thru without breaking out or if list is empty.
>+ */
>
>
> #define LIST_FOR_EACH(elem, list, type, field) \
> for ((elem) = CONTAINING_RECORD((list)->Flink, type, field); \
>
>
>- &(elem)->field != (list); \
>
>
>+ &(elem)->field != (list) || (elem = NULL); \
>
>
> (elem) = CONTAINING_RECORD((elem)->field.Flink, type, field))
>
>
>
Hi,
IMHO, this is very bad code. You use a macro to hide a 'for' loop, and
later in the source you use a 'break', 'continue' or 'goto' statement to
leave the loop or to bypass some code.
/* Find entry with SortKey greater than or equal to the
passed-in SortKey */
LIST_FOR_EACH(ReturnEntry, &DeviceQueue->DeviceListHead,
KDEVICE_QUEUE_ENTRY, DeviceListEntry)
{
/* Check if keys match */
if (ReturnEntry->SortKey >= SortKey) {
/* We found it, so just remove it */
RemoveEntryList(&ReturnEntry->DeviceListEntry);
break;
}
}
Such a source is simply unreadable.
- Hartmut
navaraf(a)svn.reactos.com wrote:
>Revert r18064 and correctly set the cell size for hash cells.
>
>Modified: trunk/reactos/ntoskrnl/cm/regfile.c
>
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/ntoskrnl/cm/regfile.c*
>
>--- trunk/reactos/ntoskrnl/cm/regfile.c 2005-09-25 20:46:28 UTC (rev 18069)
>+++ trunk/reactos/ntoskrnl/cm/regfile.c 2005-09-25 20:54:40 UTC (rev 18070)
>@@ -3033,6 +3033,7 @@
>
> else
> {
> ASSERT(SubKeyCount <= 0xffff); /* should really be USHORT_MAX or similar */
>
>
>+ NewHashBlock->CellSize = -NewHashSize;
>
>
> NewHashBlock->Id = REG_HASH_TABLE_CELL_ID;
> NewHashBlock->HashTableSize = (USHORT)SubKeyCount;
> *HashBlock = NewHashBlock;
>
>
Are you sure that this change is correct? I'm not able to install
reactos on real hardware. Reactos hangs within CmInitHives at the first
boot after the second stage setup. The same boot cd works in qemu.
- Hartmut
ion(a)svn.reactos.com wrote:
> + CsrCaptureMessageBuffer(CaptureBuffer,
> + NULL,
> + Size,
> + (PVOID*)&Request.Data.PeekConsoleInputRequest.InputRecord);
The last parameter passed to CsrCaptureMessageBuffer in your changes
looks horribly wrong. The typecast hides the bug and shouldn't be
necessary, the compiler would've warned you that this is most likely wrong.
- Thomas