Hi, For background in the Debian win32 port see the mailing list archives [1]. Basically, the only reason the port is allowed by Debian is that it could run on ReactOS or wine which are both DFSG [2] compliant. Microsoft Windows, OS/2... aren't DFSG compliant.
I've read [3] that the Debian win32 ports "failed because most unix software made unforgivable presumptions about file system semantics; mainly that you could delete files that were in-use, and rename open files on top of other open files, etc." Is this something that could be resolved? I'd imagine the Installable File System (IFS) driver would need to be modified to remember open files, or perhaps something could intercept calls to an IFS driver? I think this is what some virus scanners do, and what clamav is missing.
Porting Debian to ReactOS would give ReactOS a huge number of packages. The BSD ports collection method or gentoo's build systems may be useful too. All three would probably mean porting some base software though. Any comments about porting the base of another OS to ros? Packages like perl, bash, gcc, glibc seem to have native MS Windows ports. http://packages.debian.org/stable/base/ lists all the various packages in Debian's base (note some are specific to various ports, and there are some semi-duplicated packages).
Another advantage of a Debian win32 port using ReactOS would be a really nice flexible, modular installer (debian-installer or d-i for short). I've had problems with the ros installer in the past, specifically I couldn't install on one system without a mouse. It also asked many questions, couldn't resize partitions... d-i is nice in that it can be used with about three prompts, has partition resizing, can download additional modules... I'd suggest checking it out (I feel like I'm starting to just advertise it). Fwiw, longhorn seems to boot from a CD to do it's graphical install that is supposed to have file system resizing.
Can/does ReactOS support ELF? Alex Ionescu said that there's now an ELF loader [4]. If so, would there be anything special that would need to be done to run Linux binaries on ReactOS (beyond syscalls and porting dependencies)? Is there any advantages to the PE format? If ReactOS could support running Linux binaries it would be an easier sell to port Debian to ReactOS as it could reuse things that are already compiled for Debian. I believe the FreeBSD port (kFreeBSD that is) [5] re-uses some packages compiled for Linux. OTOH, PE would be a nicer way to go so that some support for MS Windows could be allowed... Or could MS Windows be made to support ELF? I'm afraid I also don't know much about the coff format.
[1] http://lists.debian.org/debian-win32/ [2] http://www.debian.org/social_contract#guidelines (very similar or the same as the OpenSource definition) [3] http://lists.debian.org/debian-win32/2005/10/msg00003.html Message-id: 43663BFE.9010004@liddicott.com [4] http://www.reactos.org/bugzilla/show_bug.cgi?id=293 [5] http://www.debian.org/ports/kfreebsd-gnu/
Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html
I can really see potential for this. If this was done, it could seriously add to potential for this. Although, we would need to get around those "interesting" technicalities.
Now if we can port Debian to ReactOS with the cabibility of using the drivers. (Probibly the most "interesting" aspect.) then a whole new range of possiblities could be opened up.
Seriously, being able to run a native Linux distrobution programs (Debian) and a native Windows programs on the same OS as if they were both native to the system would be fantastic.
How this would be implimented (including file system semantics) need to be carefuly thought out and designed.
On 11/25/05, Drew Scott Daniels ddaniels@umalumni.mb.ca wrote:
Hi, For background in the Debian win32 port see the mailing list archives [1]. Basically, the only reason the port is allowed by Debian is that it could run on ReactOS or wine which are both DFSG [2] compliant. Microsoft Windows, OS/2... aren't DFSG compliant.
I've read [3] that the Debian win32 ports "failed because most unix software made unforgivable presumptions about file system semantics; mainly that you could delete files that were in-use, and rename open files on top of other open files, etc." Is this something that could be resolved? I'd imagine the Installable File System (IFS) driver would need to be modified to remember open files, or perhaps something could intercept calls to an IFS driver? I think this is what some virus scanners do, and what clamav is missing.
Porting Debian to ReactOS would give ReactOS a huge number of packages. The BSD ports collection method or gentoo's build systems may be useful too. All three would probably mean porting some base software though. Any comments about porting the base of another OS to ros? Packages like perl, bash, gcc, glibc seem to have native MS Windows ports. http://packages.debian.org/stable/base/ lists all the various packages in Debian's base (note some are specific to various ports, and there are some semi-duplicated packages).
Another advantage of a Debian win32 port using ReactOS would be a really nice flexible, modular installer (debian-installer or d-i for short). I've had problems with the ros installer in the past, specifically I couldn't install on one system without a mouse. It also asked many questions, couldn't resize partitions... d-i is nice in that it can be used with about three prompts, has partition resizing, can download additional modules... I'd suggest checking it out (I feel like I'm starting to just advertise it). Fwiw, longhorn seems to boot from a CD to do it's graphical install that is supposed to have file system resizing.
Can/does ReactOS support ELF? Alex Ionescu said that there's now an ELF loader [4]. If so, would there be anything special that would need to be done to run Linux binaries on ReactOS (beyond syscalls and porting dependencies)? Is there any advantages to the PE format? If ReactOS could support running Linux binaries it would be an easier sell to port Debian to ReactOS as it could reuse things that are already compiled for Debian. I believe the FreeBSD port (kFreeBSD that is) [5] re-uses some packages compiled for Linux. OTOH, PE would be a nicer way to go so that some support for MS Windows could be allowed... Or could MS Windows be made to support ELF? I'm afraid I also don't know much about the coff format.
[1] http://lists.debian.org/debian-win32/ [2] http://www.debian.org/social_contract#guidelines (very similar or the same as the OpenSource definition) [3] http://lists.debian.org/debian-win32/2005/10/msg00003.html Message-id: < 43663BFE.9010004@liddicott.com> [4] http://www.reactos.org/bugzilla/show_bug.cgi?id=293 [5] http://www.debian.org/ports/kfreebsd-gnu/
Drew DanielsResume: http://www.boxheap.net/ddaniels/resume.html
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- My DeviantArt.com page: http://crashfourit.deviantart.com/ My FanFiction.net bio page: http://www.fanfiction.net/u/726606/ My Blog: http://crashfourit.blogspot.com/ America's Debate: http://www.americasdebate.com/
Wasn't all this the original idea behind NT? Running applications of the different OSs on as many different architectures as possible? I think we don't have many problems, that need to be solved. First, IFS has to support the UNIX-style of filesystems and second, the POSIX subsystem has to be more complete, so that it is able to run posix-compliant applications.
Greets,
David Hinz
crashfourit schrieb:
I can really see potential for this. If this was done, it could seriously add to potential for this. Although, we would need to get around those "interesting" technicalities.
Now if we can port Debian to ReactOS with the cabibility of using the drivers. (Probibly the most "interesting" aspect.) then a whole new range of possiblities could be opened up.
Seriously, being able to run a native Linux distrobution programs (Debian) and a native Windows programs on the same OS as if they were both native to the system would be fantastic.
How this would be implimented (including file system semantics) need to be carefuly thought out and designed.
-
crashfourit -
David Hinz -
Drew Scott Daniels