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(a)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 think the registry is messed up. desk.cpl isnt writing the wallpaper
style values, SystemParametersInfoW isnt wrtiting the path, and
IntSystemParametersInfo isnt able to read the wallpaper settings from
it. Also, my livecd wont boot with an error about not finding the
codepage. This all leads me to believe that something is up with the
registery. The last update i have is w3seek's where he reverted filip's
registry changes. I dont know when this started happening, last day or
so. It all worked fine when i commited 19476.
Royce: The reason you werent getting the bugcheck with my stretch patch
was because desk.cpl wasnt writing the wallpaper style values to the
registry and tat is why the wallpaper didnt stick.
I'm kinda busy right now. But hopfully within an hour I will be free
and be able to do some more debuging.
Brandon
In Short, A Lot.
ReactOS needs a proper shutdown and restart sequence (Like Linux does,
when it sends TERM to all processes). Log Off is a tad harder.
In order for Log Off to work properly, all the core processes need to
be kept running (csrss, winlogon, etc), and the system needs to "Fall
back" to a login screen. To do this, a User Logon System must be
implemented, complete with per-user registry files, settings storage,
and all the associated functions therein. AFAIK.
On 11/26/05, Alex Buell <alex.buell(a)munted.org.uk> wrote:
> On Fri, 25 Nov 2005, TwoTailedFox wrote:
>
> > No, the Shutdown/Restart and Log Off portions are in need of a
> > re-write, AFAIK. Since Local User Accounts are not implemented yet, we
> > cannot "Log Off" per se on ReactOS just yet.
>
> Ok, what needs doing to implement this properly? I'd like to help if I
> can.
>
> --
> http://www.munted.org.uk
>
> Anyone that thinks an imaginary deity is going to protect them against
> earthquakes and hurricanes needs psychiatric help.
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
"I had a handle on life, but then it broke"
> From: navaraf(a)svn.reactos.com
>
> Don't make cells smaller than they are.
Wow. Isn't it time we factor out the common code in cm, mkhive and freeldr
and put it in a static library?
GvG
navaraf(a)svn.reactos.com wrote:
> Don't make cells smaller than they are.
> Modified: trunk/reactos/ntoskrnl/cm/regfile.c
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/ntoskrnl/cm/regfile.c*
> --- trunk/reactos/ntoskrnl/cm/regfile.c 2005-11-26 13:26:48 UTC (rev 19635)
> +++ trunk/reactos/ntoskrnl/cm/regfile.c 2005-11-26 15:21:44 UTC (rev 19636)
> @@ -3431,7 +3431,7 @@
>
> RtlZeroMemory(*Cell,
> CellSize);
>
> - ((PCELL_HEADER) (*Cell))->CellSize = -CellSize;
>
> + ((PCELL_HEADER) (*Cell))->CellSize *= -1;
>
> }
>
> return STATUS_SUCCESS;
>
This change is wrong. Possible we have split the cell. In this case, we
have to set the new cell size.
- Hartmut
> From: chorns(a)svn.reactos.com
>
> Speed up compilation of ntoskrnl
Hmm, an unexpected consequence is that we can no longer enable DPRINTs per
file by removing the "#define NDEBUG" statement. At the moment, the first
source files included by io.c and cc.c (resp io/adapter.c and cc/cacheman.c)
don't define NDEBUG before including debug.h. As a result, all DPRINTs in
every file included by io.c/cc.c are enabled.
GvG