What is most important for 0.3?
Moderator: Moderator Team
Installer multiple-partition compatible, when?
One annoying problem is that the ISO installer CD doesn't manage to install REACTOS if there is more than one primary partition, and one or 2 of them NTFS.
I have Win2000 on 1st primary, Win98 on 2nd primary, and a test-environment of Win2000 on 3rd. Suse Linux is somewhere in a logical partition, and LILO on MBR.
I make 2nd primary "active" and hide 1st and 3rd. Format 2nd as FAT32. But the CD does not install REACTOS on 2nd...
And we know that Win2000 can be quite "beasty" if trying to "move" it from one primary partition to another.
So freeing 1st primary for REACTOS may be no alternative either.
So, I would like more flexibility in the installer, or an alternate installer to install REACTOS parallel to a Win98, if the partition is FAT or FAT32. Or a solution to "unpack" REACTOS manually from the ISO installer CD to c:\reactos and only install freeldr (?)
I have Win2000 on 1st primary, Win98 on 2nd primary, and a test-environment of Win2000 on 3rd. Suse Linux is somewhere in a logical partition, and LILO on MBR.
I make 2nd primary "active" and hide 1st and 3rd. Format 2nd as FAT32. But the CD does not install REACTOS on 2nd...
And we know that Win2000 can be quite "beasty" if trying to "move" it from one primary partition to another.
So freeing 1st primary for REACTOS may be no alternative either.
So, I would like more flexibility in the installer, or an alternate installer to install REACTOS parallel to a Win98, if the partition is FAT or FAT32. Or a solution to "unpack" REACTOS manually from the ISO installer CD to c:\reactos and only install freeldr (?)
NTFS support in freeldr
Your active partition is probably NTFS. It would require NTFS read support in freeldr to boot ReactOS in this case.
primary partitions
@chorns
My primary partitions were defined as follows when i tried to install reactos:
1st NTFS inactive and hidden
2nd FAT32 active + fresh formated
3rd NTFS inactive and hidden
So reactos should have installed on 2nd?
My primary partitions were defined as follows when i tried to install reactos:
1st NTFS inactive and hidden
2nd FAT32 active + fresh formated
3rd NTFS inactive and hidden
So reactos should have installed on 2nd?
Hidden partitions...
@gasmann
>Even though the partitions are hidden, they're still there.
And even hidden, they prevent REACTOS installer from doing it's job?
Should i change the type of these partitions from "hidden NTFS" to something like "undefined" or so? (i can lookup possible partition type codes in linux fdisk)
Or is "2nd partition" always a problem for the installer, whatever partition codes 1st and 3rd have? Can REACTOS install only on "1st"?
info: i'm talking about reactos-2.6-REL
>Even though the partitions are hidden, they're still there.
And even hidden, they prevent REACTOS installer from doing it's job?
Should i change the type of these partitions from "hidden NTFS" to something like "undefined" or so? (i can lookup possible partition type codes in linux fdisk)
Or is "2nd partition" always a problem for the installer, whatever partition codes 1st and 3rd have? Can REACTOS install only on "1st"?
info: i'm talking about reactos-2.6-REL
Re: Hidden partitions...
I think so, yes... It's also mentioned at the start in the setup that it only supports one primary partition (see limitations).steveh wrote:Or is "2nd partition" always a problem for the installer, whatever partition codes 1st and 3rd have? Can REACTOS install only on "1st"?
Easiest thing you could do is make an image of the first partition remove it, install ReactOS and then write this image back to drive... And then boot ReactOS with a freeldr bootfloppy.
If you want me to I also could upload the binaries (=the reactos folder that should be on hdd) of the 0.2.6-release somewhere and you could unzip it where you want it without removing the partition.
I think it'd be easier and more secure than making images of partintions and adding and removing them taking the sources and modifying them to use the 2nd partitions instead of the first one. I don't know if it's easy to change (haven't seen the source ), but the work would improve the reactos community.
Without application compatability ReactOS could turn into another Wine. I've been following Wine since 1998 and there is still a mountain of Windows appliactions which kinda-sorta run but not very well, or don't run well enough to be usable. Without Windows application compatability ReactOS might as well be SkyOS.Since we already have some level of compatiblity to show off that it can be done. For now on it is just a matter of time.
The update feature would make testing easier and would show testers/users that the OS is being developed constantly. Also it would enable people easier way to actually using the OS since they don't have to i.e. make new install every time new version comes along.
Besides, the compatibility is developing constantly even if the update feature would be priority #1. (Because every dev wouldn't be occupied by the update feature) Also introducing the feature at this point would be easier than in later phase when the OS is starting to form into shape.
I dont really see the point to your post, but just like WINE ReactOS will take time.chris319 wrote:Without application compatability ReactOS could turn into another Wine. I've been following Wine since 1998 and there is still a mountain of Windows appliactions which kinda-sorta run but not very well, or don't run well enough to be usable. Without Windows application compatability ReactOS might as well be SkyOS.
Your trying to hit a moving target.Longhorn will intorduce 3D desktop APIs.ScoTTie wrote:I dont really see the point to your post, but just like WINE ReactOS will take time.chris319 wrote:Without application compatability ReactOS could turn into another Wine. I've been following Wine since 1998 and there is still a mountain of Windows appliactions which kinda-sorta run but not very well, or don't run well enough to be usable. Without Windows application compatability ReactOS might as well be SkyOS.
So we'll introduce 3D desktop APIs. Thing is I haven't met that many serious computer users who are willing to upgrade to Longhorn as it appears to be becoming and software developers will always seek backwards compatability.
Here's a thought though, Longhorn is coming out in 2006 (current timetable), after that there will be no new releases for god knows how long and we can/are progressing much faster than Longhorn is atm. Given enough time we will catch up.
Here's a thought though, Longhorn is coming out in 2006 (current timetable), after that there will be no new releases for god knows how long and we can/are progressing much faster than Longhorn is atm. Given enough time we will catch up.
Windows will always remain a moving target. Or rather, the new version will never be completely compatible with, and add features compared to previous versions. However, those previous versions and the software and drivers written for them won't change.reub2000 wrote: Your trying to hit a moving target.Longhorn will intorduce 3D desktop APIs.
The way I see it, ROS will first co-exist with Windows in a more or less parasitic relationship until it has grown enough (after a number of years) to begin dictating its own rules ("embrace and extend"), at which point compatibility with Windows will become less and less important.
Who is online
Users browsing this forum: No registered users and 40 guests