On 2014.01.03 18:58, Thomas Mueller wrote:
> What I would like to do, and about the only way I can see and test
> ReactOS, is to build from RosBE from FreeBSD or Linux, or Wine, and
> install onto a USB stick without having to make an intermediate
> boot/installation medium.
Then today may be your lucky day... ;)
But first things first (you may skip this part if you're only interested
in UNIX, as Rufus is Windows only): Besides ISO support through
Syslinux, the new BETA of Rufus [1] also adds the ability to install the
ReactOS boot records, so that one can then boot freeldr.sys directly
from USB. Unlike what's the case for the ISO, this is a bare install, so
you will still need to copy your own freeldr.sys, freeldr.ini and
relevant files to the USB. However, the hard part of the install
(modifying the boot records) should now be taken care of for you.
Now, since this is an advanced feature, it's not made available in the
UI by default. To access the bare ReactOS boot record installation, you
must first enable Advanced Mode in Rufus, by clicking the white triangle
next to "Format Options" and only then will you see "ReactOS" listed in
the "Create a bootable disk" dropdown. It's the same way Rufus provides
bare installation of Syslinux v4 & v5 boot records.
I tested freeldr.sys boot from USB using this method, after copying the
same set of files as the one ReactOS creates for second stage
installation, and it seems to work as good as one might expect (boots
brilliantly, but then runs into ReactOS 0x7b, due to issues with USB
support - at least on the systems I'm testing with).
I may eventually use this method to support ISOs, but for now, I'll
stick with the syslinux -> mboot.c32 -> setupldr.sys for ISO support,
while the direct freeldr.sys for more adventurous people.
Now, what may be of more interest for UNIX-derivative users, is that
what Rufus really uses behind the scenes to install boot blocks is its
own integrated version of ms-sys [2]. Thus, since I added ReactOS
support in my own embedded version of ms-sys, I also went ahead and
produced a generic UNIX version that can install the ReactOS bootblocks
from the commandline, for freeldr support.
To use it, you'll first need to clone the relevant github repository [3]
and then switch to the "rufus" branch of that repo, which is where I
added the changes.
I'm also providing a fully detailed example of a run (git clone, branch
switch, installation, etc), in the attached log, but basically, what you
want to run is:
1. Fetching & compiling the source
# git clone https://github.com/pbatard/ms-sys.git
# cd ms-sys/
# git checkout rufus
# make
2. Installing the ReactOS boot blocks on an USB drive, here /dev/sda,
after blanking its first sectors:
# dd if=/dev/zero of=/dev/sda bs=8M count=8
# fdisk /dev/sda => create a FAT32 bootable partition
# mkdosfs -F 32 /dev/sda1
# ./bin/ms-sys -0 /dev/sda => install the ReactOS MBR
# ./bin/ms-sys -O /dev/sda1 => install the ReactOS FAT32 PBR
# ./bin/ms-sys -p /dev/sda1 => write partition info [REQUIRED!]
Then you can just copy your files, and boot the drive.
Note that the MBR option is -0 (minus zero) and the second -O (minus
uppercase O), and also that your drive _will NOT boot_ unless you also
apply the -p option. Oh and if you want to complain about ms-sys (yeah,
it would probably be nicer if it used getopt so that you could run
multiple options at once), please remember that:
1. I am not the author of ms-sys
2. I use my own non-commandline, non-UNIX compatible version in Rufus
This means that, due to time constraints, I have little interest in
improving my UNIX/ReactOS version of ms-sys (to add ext2 support for
instance). I created it as fast as I could, in the hope that it would be
useful for UNIX people (only tested FAT32 - I kind of expect FAT16 to be
broken), and I may see with the author (Henrik Carlqvist) if he wants to
integrate the ReactOS patches, but that'll be about it.
> There ought to be something like "make install DESTDIR=...".
Hopefully, now that you can use ms-sys on Linux/FreeBSD, you should be
able to add an install step, that can invoke ms-sys to create a whole
Live/USB system from scratch, to install the newly generated development
binaries.
"All" that remains then, is to fix USB support in ReactOS, so that such
a system can run as expected... ;)
Regards,
/Pete
[1] http://rufus.akeo.ie/downloads/
[2] http://ms-sys.sourceforge.net/
[3] https://github.com/pbatard/ms-sys/tree/rufus
root@sheeva:/usr/src# git clone https://github.com/pbatard/ms-sys.git
Cloning into ms-sys...
remote: Counting objects: 306, done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 306 (delta 203), reused 302 (delta 199)
Receiving objects: 100% (306/306), 84.59 KiB, done.
Resolving deltas: 100% (203/203), done.
root@sheeva:/usr/src# cd ms-sys/
root@sheeva:/usr/src/ms-sys# git checkout rufus
Branch rufus set up to track remote branch rufus from origin.
Switched to a new branch 'rufus'
root@sheeva:/usr/src/ms-sys# make
mkdir -p dep
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/partition_info.d src/partition_info.c > dep/partition_info.d
mkdir -p obj
mkdir -p bin
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/partition_info.o src/partition_info.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/ntfs.d src/ntfs.c > dep/ntfs.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/ntfs.o src/ntfs.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat12.d src/fat12.c > dep/fat12.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat12.o src/fat12.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat16.d src/fat16.c > dep/fat16.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat16.o src/fat16.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/file.d src/file.c > dep/file.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/file.o src/file.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/br.d src/br.c > dep/br.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/br.o src/br.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/nls.d src/nls.c > dep/nls.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/nls.o src/nls.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/main.d src/main.c > dep/main.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/main.o src/main.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat32.d src/fat32.c > dep/fat32.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat32.o src/fat32.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/identify.d src/identify.c > dep/identify.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/identify.o src/identify.c
cc -o bin/ms-sys obj/partition_info.o obj/ntfs.o obj/fat12.o obj/fat16.o obj/file.o obj/br.o obj/nls.o obj/main.o obj/fat32.o obj/identify.o
mkdir -p mo
msgfmt -o mo/sv.mo po/sv.po
root@sheeva:/usr/src/ms-sys# dd if=/dev/zero of=/dev/sda bs=8M count=8
8+0 records in
8+0 records out
67108864 bytes (67 MB) copied, 2.41523 s, 27.8 MB/s
root@sheeva:/usr/src/ms-sys# fdisk /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x7759d579.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4, default 1): 1
First sector (2048-63487999, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-63487999, default 63487999):
Using default value 63487999
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): a
Partition number (1-4): 1
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
root@sheeva:/usr/src/ms-sys# mkdosfs -F 32 /dev/sda1
mkdosfs 2.11 (12 Mar 2005)
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -0 /dev/sda
ReactOS master boot record successfully written to /dev/sda
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys /dev/sda
/dev/sda has an x86 boot sector,
it is a ReactOS master boot record, like the one this
program creates with the switch -r on a hard disk device.
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -O /dev/sda1
FAT32 ReactOS boot record successfully written to /dev/sda1
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -p /dev/sda1
Start sector 2048 (nr of hidden sectors) successfully written to /dev/sda1
Physical disk drive id 0x80 (C:) successfully written to /dev/sda1
Number of heads (64) successfully written to /dev/sda1
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys /dev/sda1
/dev/sda1 has a FAT32 file system.
/dev/sda1 has an x86 boot sector,
it is exactly the kind of FAT32 ReactOS boot record this program
would create with the switch -O on a FAT32 partition.
root@sheeva:/usr/src/ms-sys# mount /dev/sda1 /mnt/usb/
root@sheeva:/usr/src/ms-sys# ls /ext/reactos_files/
ReactOS/ freeldr.ini freeldr.sys
root@sheeva:/usr/src/ms-sys# ls /mnt/usb
root@sheeva:/usr/src/ms-sys# cp -r /ext/reactos_files/* /mnt/usb
root@sheeva:/usr/src/ms-sys# ls /mnt/usb
ReactOS/ freeldr.ini* freeldr.sys*
root@sheeva:/usr/src/ms-sys# umount /mnt/usb
root@sheeva:/usr/src/ms-sys#
Pete Batard schreef op 3-1-2014 3:59:
> If you want to test, you can pick the latest ALPHA from:
> http://rufus.akeo.ie/downloads/
Awesome, will test using USB2 ports.
> Currently, the way this works is through installing Syslinux (v4.07) and
> mboot.c32 so that setupldr.sys can then be invoked (see the
> /syslinux.cfg created by Rufus on the drive).
>
> Also, for the time being, only setupldr.sys will be referenced (no
> freeldr.sys) on account that:
FreeLDR as multiboot-kernel only looks at freeldr.ini at C:\ , no idea
if your created USB stick counts as C: or A:.
Also ReactOS might write freeldr.ini in some special way on FAT drives,
I've never been able to open/modify it using a DOS text editor.
> 1. The Syslinux's menu.c32 file is rather large, and I want to keep
> Rufus small, so I don't want to embed it in the application (which is
> also the mais reason why Rufus doesn't include native GRUB support). But
> this means that user selection from a menu is not available.
>
> 2. When testing, I couldn't get freeldr.sys to do much when booted from
> USB... though that was most likely because I hadn't actually installed
> ReactOS anywhere.
Smallest I've gotten FreeLDR is through using
SYSLINUX -> MEMDISK -> FLOPPY.GZ where floppy.gz is a compressed ReactOS
startup diskette image. SYSLINUX -> MBOOT.C32 -> FREELDR.GZ might also
work instead.
> Still, I'm hoping that making the creation of a bootable UFD easier for
> ReactOS will help encourage more people to test it and help the project.
I've always hoped for Syslinux -> Memdisk/GRUB -> ReactOS.ISO/IMG simply
to overcome lack of mass storage controllers drivers by running from RAM.
> Of course, I'm also open to suggestions to try to improve support for
> ReactOS in Rufus, if you want something specific. For instance, I should
> point out that the syslinux.cfg created by Rufus is written before any
> of the ISO files are copied over. Thus, if the ReactOS ISOs were to
> include their own syslinux.cfg & menu.c32/vesamenu.c32, it would be very
> easy to provide menu selection for the user when booting from USB, even
> as the ISOs are not Syslinux/Isolinux based.
So right now the installer ISO works but not the LiveCD/USB?
[ https://www.reactos.org/getbuilds ] with rev 61493
Thanks for having implemented the support Pete! :)
Have fun with HaikuOS :)
best wishes for 2014,
Bernd
Hi!
since 2013 is almost over, it is time to make some plans for 2014.
My primary goals for 2014 are:
- Completing the user account management, user logon and password change.
- Fixing winlogon.exe in order to enable users to lock and unlock the
computer and to change their identity (log-off and log-on again).
- Fix potential bugs in userenv.dll. We need to get rid of the
administrator logon hack in syssetup.dll.
- Fix the system shutdown: We need to terminate applications and
services before the machine shuts down.
Secondary goals are:
- Implement PNP support for scsiport.sys.
- Improvements to PNP and driver installation.
- Get some legacy hardware working (parallel port, PCMCIA).
The items of this list and their priorities are not fixed. I reserverve
the right to make changes to this list or to work on something entirely
different, without prior notice.
Happy new year!
Regards
Eric
Hi,
this message is a bit provocative, but please don't be offended by it.
You all did a wonderful work during this year. Thank you!
It's very good to see the work is going on. Just for fun, when I had
spare 15 minutes, I decided to check, what was done in the win32
subsystem during this year by the major, respectable and very old time
ReactOS developer, and whether my proposal with Arwinss still stands or not.
Here is what I found: (analyzing ~ 62 commits by jimtabor):
- 25 revisions: Fixes/hacks of our code (ReactOS-specific bug, works in
Wine, sometimes says in comments "//// ReactOS : Justin Case something
goes wrong.") (revs 58528, 58562, 58563, 58633, 58773, 58999, 59000,
59201, 60054, 60587, 60590, 60592, 60622, 60626, 60659, 60676, 60677,
60881, 61078, 61079, 61142, 61250, 61251, 61292, 61458)
- 13 revisions: Syncs with Wine (revs 59157, 59158, 59159, 60763, 60784,
60807, 60820, 60858, 60863, 60865, 60867, 61244, 61422)
- 14 revisions: Own code development or rewriting old code, some of
which might have been derived from ancient versions of Wine.
(60387, 60389, 60394, 60539, 60599, 60602, 60660, 60682, 60683, 60684,
60718, 60883, 60976, 60992)
- 1 revision: attempt to fix a bug found in Wine (revision 60054, issue
CORE-6024)
You don't need to be a scientist to see that 61% of the changes went
into fixing ReactOS specific bugs or just bringing in newer Wine code to
fix old Wine bugs. Remaining 22% of efforts was spent on actually
developing our own, assumingly better code, and just 1 revision was
spent on such a glorious thing as fixing Wine's bug.
ReactOS is a just for fun type of project, so I highly appreciate that
efforts were put into all of the above!
However, I still think that it would be beneficial if someone would put
similar efforts into Arwinss to eliminate the need to bring in hacks and
fix stuff which works in Wine for years already, and focus on developing
only those parts which we obviously can't share (GDI, hardware
accelerated graphics, whatever else).
I lack time to do this myself, but if anyone volunteers I would be glad
to help, share my experience and think up of interesting tasks. Like,
getting Arwinss to work in Windows 2003 instead of its native subsystem,
which would be a nice test.
Regards,
Aleksey Bragin
On 2013-12-25 23:47, pschweitzer(a)svn.reactos.org wrote:
> +TryWithVolumeName:
> + /* If we didn't find anything, try differently */
> + if (DeviceLength < 2 * sizeof(WCHAR) || DeviceString[2] != L':')
This looks like a buffer overrun. Did you mean < 3 * sizeof(WCHAR)?
A pity.
-------- Original Message --------
Subject: Your stand proposal for ReactOS has been rejected
Date: Mon, 16 Dec 2013 22:28:19 +0100 (CET)
From: FOSDEM Stands Team <stands(a)fosdem.org>
To: Aleksey Bragin <aleksey(a)reactos.org>
Hi Aleksey,
The FOSDEM stands team is sorry to have to inform you that your request
for a stand for ReactOS has been rejected.
We have received almost twice as many proposals as we could accept,
and we regret not being able to give everyone a stand.
We hope to see you at FOSDEM 2014 in a different capacity regardless.
Kind regards,
Wynke Stulemeijer
FOSDEM stands team
This is a suboptimal way of handling it, because it will cause the
compiler to instantiate all GUIDs in all compilation units. When linking
only one will be selected for the executable, but still it increases the
size of all object files. If it is to allow a precompiled header, I
suggest adding an additional guid.c file, that only includes the guid
headers, not the precompiled header.
Timo
Am 24.12.2013 21:58, schrieb akhaldi(a)svn.reactos.org:
> Author: akhaldi
> Date: Tue Dec 24 20:58:27 2013
> New Revision: 61381
>
> URL: http://svn.reactos.org/svn/reactos?rev=61381&view=rev
> Log:
> [USBSTOR]
> * Define INITGUID in the main header.
> CORE-7716
>
> Modified:
> trunk/reactos/drivers/usb/usbstor/usbstor.c
> trunk/reactos/drivers/usb/usbstor/usbstor.h
>
> Modified: trunk/reactos/drivers/usb/usbstor/usbstor.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/usbstor/usbsto…
> ==============================================================================
> --- trunk/reactos/drivers/usb/usbstor/usbstor.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/usb/usbstor/usbstor.c [iso-8859-1] Tue Dec 24 20:58:27 2013
> @@ -10,7 +10,6 @@
>
> /* INCLUDES ******************************************************************/
>
> -#define INITGUID
> #include "usbstor.h"
>
> #define NDEBUG
>
> Modified: trunk/reactos/drivers/usb/usbstor/usbstor.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/usbstor/usbsto…
> ==============================================================================
> --- trunk/reactos/drivers/usb/usbstor/usbstor.h [iso-8859-1] (original)
> +++ trunk/reactos/drivers/usb/usbstor/usbstor.h [iso-8859-1] Tue Dec 24 20:58:27 2013
> @@ -1,5 +1,7 @@
>
> #pragma once
> +
> +#define INITGUID
>
> #include <ntddk.h>
> #include <usbdi.h>
>
>
>