reactos-kernel

[ros-kernel] CVS Commit: reactos

[KJK::Hyperion <no...@li...>]

Modified files:
     services/dd/null/makefile
     services/dd/null/null.c

Added files:
     services/dd/null/null.h

Fixed bugs in null device driver, added zero stream device

AW: [ros-kernel] Ton-O-Bugs

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	KJK::Hyperion [SMTP:no...@li...]
> Gesendet am:	Montag, 29. April 2002 16:41
> An:	ReactOS-Kernel
> Betreff:	[ros-kernel] Ton-O-Bugs
>
>   - major flaw in our toolchain: GNU ld doesn't calculate the PE image
> checksum, it just happily sets it to zero. Apparently no command line
> switch controls this. NT refuses to load drivers with an incorrect 
checksum
> (can't test the new Null driver because of this)

I've written a litle tool that calculates the PE checksum and changes some 
memory attributes. You can compile it with 'gcc -o pesum.exe pesum.c' and 
use it with 'pesum image_in image_out'.

- Hartmut

 

[ros-kernel] About global POSIX, oops, *subsystem* data again

[KJK::Hyperion <no...@li...>]

Hi all. I'm continuing my work on... "some subsystem", and I'm facing an 
old problem: where to store global data? Or better: how to get at it? 
Casper suggested me, long time ago, to use some reserved field in the PEB 
as a pointer to the data, and I think it's the best solution, but before 
changing such an important part of the system I want public approval from 
the team

Re: [Fwd: Re: [ros-kernel] Re: File system struct - ENOUGH ALREADY]

[KJK::Hyperion <no...@li...>]

At 15.23 30/04/2002, you wrote:
>Try moving a large app between drives under Windows...
>This changes the path, often requiring a reinstall, or some messy registry 
>edits.

Actually, it's possible and quite funny. You can unmount all disks, even 
those in use, even the system disk, ending up with a system without drive 
letters, then remount them as you like. I used this, together with some 
symlink magic, to trick the PSDK installer. I have the program files dir 
mounted on a different partition that had 3 GBs free, but the letter was 
D:, the system partition, with only 70 MBs free. I unmounted all disks, 
mounted the program files partition as D:, mounted the system partition as 
D:\system, created symlinks to simulate a system partition (D:\WINNT => 
D:\system\WINNT, for example), installed the PSDK. Sadly, the logon manager 
will always delete all mount points on logoff, so you need to reboot after

Re: [ros-kernel] Re: File system struct - ENOUGH ALREADY

[KJK::Hyperion <no...@li...>]

At 14.16 30/04/2002, you wrote:
> > >I think you give up to easily. One problem is that you are trying to turn
> > >ReactOS itself into a POSIX environment, instead of taking advantage of
> > >the ReactOS subsystem abillity.
> > My point of view, which I won't try to defend any further (at least for a
> > very long time), is to mix the best of all subsystems. The Win32 
> "standard"
> > for filesystem structure is hardly the "best". Drive letters are hardly 
> the
> > best way to identify devices.
>The /dev directory on my Mandrake Linux look like this:

Linux has a flat /dev, except for the USB root. It's not /dev the bad idea, 
a flat /dev is

>Also the root directory on the Mandrake Linux has the following entries:
[...]
>initrd

nonstandard

>lost+found

ext2 crap

>root

nonstandard

>swap

nonstandard

>Why is this a better layout than that on my Windows NT partition?
>Documents & Settings
>Program Files
>Windows

Read the FHS:
<http://www.pathname.com/fhs/>

I have no patience to explain something that *books* have been written about

>And finally, why shouldn't I be able to assign my CD-ROM a drive letter?

never said this

> > Multiple roots are bad, they are the
> > inheritance of an era (DOS) when there was no distinction between the
> > operating system and the user interface, but we don't need them anymore
>Sure we need them. You talk of DOS as if we did not learn from it and it 
>is not usable when really, DOS has survived for many years. Consumers are 
>used to have drive letters. Changing them will cause confusion. If ReactOS 
>is ever going to reach Windows users, the project must focus on the users.

no comment. Remember that the posts to this list are archived

[ros-kernel] Re: Ton-O-Bugs

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	we...@cw... [SMTP:we...@cw...]
> Gesendet am:	Dienstag, 30. April 2002 15:21
> An:	Jason Filby
> Cc:	Eric Kohl; ReactOS Kernel
> Betreff:	Re: [ros-kernel] Ton-O-Bugs
>
> But I can't reproduce the problem;
> could someone post a fully decoded stack trace?


Sometimes I see no stack frame, if there is a stack frame, it starts with 
_irq_handler_0 and _irq_handler_14. On real hardware there isn't printed a 
stack frame.

- Hartmut

E:\SandBox\Ros\bochs>setup
installing from \sandbox\ros\reactos_work\reactos\ to c:\reactos
deleting old c:\reactos
making dir structure
copying files
install complete
========================================================================
                      Bochs x86 Emulator 1.4.pre1
                             March 5, 2002
========================================================================
00000000000i[     ] reading configuration from .bochsrc
00000000000i[     ] using log file bochsout.txt
(ke/main.c:915) Module: 'ntoskrnl.exe' at c0000000, length 0x000ac000
(ke/main.c:915) Module: 'system32\hal.dll' at c00ac000, length 0x0000b000
(ke/main.c:915) Module: 'bootc.lst' at c00b7000, length 0x00001000
(ke/main.c:915) Module: 'system32\drivers\scsiport.sys' at c00b8000, length 
0x00007000
(ke/main.c:915) Module: 'system32\drivers\atapi.sys' at c00bf000, length 
0x00007000
(ke/main.c:915) Module: 'system32\drivers\class2.sys' at c00c6000, length 
0x00008000
(ke/main.c:915) Module: 'system32\drivers\disk.sys' at c00ce000, length 
0x00006000
(ke/main.c:915) Module: 'system32\drivers\cdrom.sys' at c00d4000, length 
0x00005000
(ke/main.c:915) Module: 'system32\drivers\vfatfs.sys' at c00d9000, length 
0x00012000
(ke/main.c:915) Module: 'system32\drivers\cdfs.sys' at c00eb000, length 
0x00009000
(ke/main.c:915) Module: 'system32\config\system.hiv' at c00f4000, length 
0x00001000
(ke/main.c:963) Process registry chunk at c00f4000
(ke/main.c:985) Processing module 'system32\drivers\scsiport.sys' at 
c00b8000, length 0x00007000
(ldr/loader.c:1594) DriverBase: cca48000
(ldr/loader.c:1799) Module name is: \Modules\scsiport.sys
ScsiPort Driver 0.0.1
(ke/main.c:985) Processing module 'system32\drivers\atapi.sys' at c00bf000, 
length 0x00007000
(ldr/loader.c:1594) DriverBase: cca50000
(ldr/loader.c:1799) Module name is: \Modules\atapi.sys
ATAPI Driver 0.0.1
(atapi.c:499) Primary channel!
(atapi.c:1538) SCSIOP_INQUIRY: DeviceExtension c0273a4a  TargetId: 0
(atapi.c:1598) VendorId: 'Generic 1234        '
(atapi.c:1538) SCSIOP_INQUIRY: DeviceExtension c0273a4a  TargetId: 1
(atapi.c:1598) VendorId: 'Generic 1234        '
(ke/main.c:985) Processing module 'system32\drivers\class2.sys' at 
c00c6000, length 0x00008000
(ldr/loader.c:1594) DriverBase: cca58000
(ldr/loader.c:1799) Module name is: \Modules\class2.sys
Class Driver 0.0.1
(ke/main.c:985) Processing module 'system32\drivers\disk.sys' at c00ce000, 
length 0x00006000
(ldr/loader.c:1594) DriverBase: cca61000
(ldr/loader.c:1799) Module name is: \Modules\disk.sys
Disk Class Driver 0.0.1
(ke/main.c:985) Processing module 'system32\drivers\cdrom.sys' at c00d4000, 
length 0x00005000
(ldr/loader.c:1594) DriverBase: cca68000
(ldr/loader.c:1799) Module name is: \Modules\cdrom.sys
CD-ROM Class Driver 0.0.1
(ke/main.c:985) Processing module 'system32\drivers\vfatfs.sys' at 
c00d9000, length 0x00012000
(ldr/loader.c:1594) DriverBase: cca6e000
(ldr/loader.c:1799) Module name is: \Modules\vfatfs.sys
(ke/main.c:985) Processing module 'system32\drivers\cdfs.sys' at c00eb000, 
length 0x00009000
(ldr/loader.c:1594) DriverBase: cca82000
(ldr/loader.c:1799) Module name is: \Modules\cdfs.sys
CDFS 0.0.1
(ke/main.c:994) CommandLine: multi(0)disk(0)rdisk(0)partition(1)\reactos 
/DEBUGPORT=BOCHS
Double Fault Exception: 8(0)
CS:EIP 8:c0002470 <ntoskrnl.exe: 2470,_KeIRQTrapFrameToTrapFrame>
cr2 c0091ffc cr3 0 Proc: c021418a Pid: 1 <SYSTEM> Thrd: c0214aae Tid: 1
DS 10 ES 10 FS 30 GS 10
EAX: c00920dc   EBX: cca4a4b8   ECX: 000000bf
EDX: 000000a1   EBP: c00920cc   ESI: 00000000
EDI: c02813a8   EFLAGS: 00010087 kESP c0092000 kernel stack base c0092000
ESP c0092000
Frames:
{<ntoskrnl.exe: 32ee,_irq_handler_14>}*20
<ntoskrnl.exe: 3040,_irq_handler_0>
{<ntoskrnl.exe: 32ee,_irq_handler_14>}*12
<hal.dll: 55a3,@KfLowerIrql@4>
<hal.dll: 55bf,_KeLowerIrql@4>
<ntoskrnl.exe: 100c5,_KeSynchronizeExecution@12>
<\Modules\scsiport.sys: 1da6,_ScsiPortStartIo@8>
<ntoskrnl.exe: 3710c,_IoStartPacket@16>
<\Modules\scsiport.sys: 1a11,_ScsiPortDispatchScsi@8>
<ntoskrnl.exe: 33e8d,@IofCallDriver@8>
<ntoskrnl.exe: 33eb7,_IoCallDriver@8>
<\Modules\class2.sys: 3236,_ScsiClassReadWrite@8>
<ntoskrnl.exe: 33e8d,@IofCallDriver@8>
<ntoskrnl.exe: 33eb7,_IoCallDriver@8>
<\Modules\vfatfs.sys: 1080,_VfatWriteSectors>
<\Modules\vfatfs.sys: 9ee5,_VfatWriteFileData>
<\Modules\vfatfs.sys: afc3,_VfatWrite>
...

Re: [ros-kernel] Re: File system struct - ENOUGH ALREADY

[Casper H. <ch...@us...>]

tir, 2002-04-30 kl. 14:53 skrev Frank D. Engel, Jr.:
> > Why is this a better layout than that on my Windows NT partition?
> 
> For a single-drive, mini-system without the need for advanced I/O
> optimizations...  it's not.

How could the Windows layout prevent you from optimizing I/O?

> 
> But, if you are dealing with a large system, having many drives, and
> attempting to seamlessly integrate those drives into a cohesive, usable
> layout... it can be significantly better.
> 
> Software is typically stored in /usr, /bin, /opt, and /sbin.  IRIX, for
> example, has /bin as a symlink to /usr/bin.  /usr is a good candidate
> for a mount point to a large parition on a separate drive.  Another
> good candidate is home directories (/home under Linux; /export/home
> under Solaris -- server-side; /usr/people under IRIX; etc.)  This is
> where the documents are stored.  Additionally, moving /tmp to a
> separate partition (or better yet to swap space, as in Solaris), can
> help to prevent users from flooding the boot device with large files,
> adding to the system's stability.
> 

You can also use quotas to prevent flooding of a system. This way you
get more control and it is definitely easier to change quotas than
resizing partitions in case you need more disk space.

> On the other hand, a single-user, home system can put all of these onto
> a single partition, allowing space to be managed much more easily.  If
> a second drive is added, with a new partition for, say, home
> directories...
> 
> 1. make the partition(s)
> 2. mkfs the partition(s)
> 3. shutdown now  (to single-user mode, after warning users)
> 4. mount the partition on, say, /mnt/temporary
> 5. mv /home/* /mnt/temporary
> 6. umount /mnt/temporary
> 7. mount /dev/newpartition /home
> 8. adjust fstab
> 9. telinit 5  (or 3)
> 
> This gives *NIX systems a LOT more flexibility when it comes to disk
> management.  And, the above procedure does not break existing software,
> or require reinstallations...
> 
> Try moving a large app between drives under Windows...
> This changes the path, often requiring a reinstall, or some messy
> registry edits.
> 
> > /mnt/cdrom
> > 
> > better than
> > 
> > D:
> > 
> > for accessing my CD-ROM?
> 
> Once more, what if you add another drive, and your drive letter
> changes?  Some of those games might not work anymore until you
> reinstall them!

If I want a partition to have a specific drive letter I would go into
disk management in control panel and change the drive letter. If I want
the partition to not have a drive letter, I could mount it in an NTFS
directory. If I have two partitions but want only one drive letter for
them both, I could use a software RAID driver.

Why would you move your applications manually? The Windows NT policy in
this area is to keep applications in the Program Files directory. Try
moving samba on linux. The location of smb.conf is generally hardcoded
in the program, so moving it will render it unusable. On my Mandrake
installation it is located in /etc/samba, but I've seen it in /etc,
/usr/local/samba, and /usr/local/lib too.

> 
> > Your arguments:
> > "The Win32 "standard" for filesystem structure is hardly the "best".
> > Drive letters are hardly the best way to identify devices."
> > are not good enough for me to agree with you.
> 
> Does it make a little more sense now?
> 
> > Yes, NT is not a microkernel. NT has microkernel principals in it's
> > design, but it is not a true microkernel because it is comercially
> > impractical. AKAIK, no comercial operating systems implement a true
> > microkernel design. Since someone claim that MS says it is, I would
> 
> The BeOS used a true microkernel.  And, it was BLAZING fast.  (I think
> you can still DL the personal edition for free from cNet.)  Much of
> POSIX, FAST, GUI-based, FAST, easy to work with, FAST, fun, FAST...

I think your FAST key is stuck ;o)

> 
> > be
> > glad if someone would post a link to some official statement from MS,
> > because I have never heard them say this. The only information I have
> > about this is from Inside Microsoft Windows 2000 published by
> > Microsoft
> > Press.
> 
> 
> http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/ntwrkstn/reskit/archi.asp
> 
> M$ refers to NT as having a "modified" microkernel architecture, as
> opposed to a "pure" microkernel architecture.

And they are right.

[Fwd: Re: [ros-kernel] Re: File system struct - ENOUGH ALREADY]

[Casper H. <ch...@us...>]

Re: [ros-kernel] Ton-O-Bugs

[<we...@cw...>]

Quoting Jason Filby <jas...@ya...>:
> 
> So it's a known IRQ bug? Can you tell me any more about it?
> 
The problem is reentrancy into the interrupt handler caused why
Philip Susi's changes of a week ago. But I can't reproduce the problem;
could someone post a fully decoded stack trace?

Re: [ros-kernel] Re: File system struct - ENOUGH ALREADY

[Casper H. <ch...@us...>]

tir, 2002-04-30 kl. 04:20 skrev KJK::Hyperion:
> At 02.14 30/04/2002, you wrote:
> >I think you give up to easily. One problem is that you are trying to turn 
> >ReactOS itself into a POSIX environment, instead of taking advantage of 
> >the ReactOS subsystem abillity.
> 
> My point of view, which I won't try to defend any further (at least for a 
> very long time), is to mix the best of all subsystems. The Win32 "standard" 
> for filesystem structure is hardly the "best". Drive letters are hardly the 
> best way to identify devices.

The /dev directory on my Mandrake Linux look like this:

crw-------    1 root     root      10,  10 aug 30  2001 adbmouse
crw-------    1 root     audio     14,  14 aug 30  2001 admmidi0
crw-------    1 root     audio     14,  30 aug 30  2001 admmidi1
...
crw-rw----    1 root     disk      27,  17 aug 30  2001 zqft1
crw-rw----    1 root     disk      27,  18 aug 30  2001 zqft2
crw-rw----    1 root     disk      27,  19 aug 30  2001 zqft3

5699 entries! Why is this way so much better than the NT way, where
drivers register device objects with the object manager?

Also the root directory on the Mandrake Linux has the following entries:

bin
boot
dev
etc
home
initrd
lib
lost+found
mnt
opt
proc
root
sbin
swap
tmp
usr
var

Why is this a better layout than that on my Windows NT partition?

Documents & Settings
Program Files
Windows

And finally, why shouldn't I be able to assign my CD-ROM a drive letter?

Is

/mnt/cdrom

better than

D:

for accessing my CD-ROM?

Your arguments:
"The Win32 "standard" for filesystem structure is hardly the "best".
Drive letters are hardly the best way to identify devices."
are not good enough for me to agree with you.

 Multiple roots are bad, they are the 
> inheritance of an era (DOS) when there was no distinction between the 
> operating system and the user interface, but we don't need them anymore

Sure we need them. You talk of DOS as if we did not learn from it and it
is not usable when really, DOS has survived for many years. Consumers
are used to have drive letters. Changing them will cause confusion. If
ReactOS is ever going to reach Windows users, the project must focus on
the users.

> One more thing: NT is NOT a microkernel, so please stop considering it 
> such. It may make sense to have special filesystems (think /proc) 
> implemented by subsystems, ON A MICROKERNEL SYSTEM, that will surely 
> provide facilities to implement system calls as IPC calls. But, alas, NT 
> isn't, so it's just not going to work. At least, not to the extent you'd hope

Yes, NT is not a microkernel. NT has microkernel principals in it's
design, but it is not a true microkernel because it is comercially
impractical. AKAIK, no comercial operating systems implement a true
microkernel design. Since someone claim that MS says it is, I would be
glad if someone would post a link to some official statement from MS,
because I have never heard them say this. The only information I have
about this is from Inside Microsoft Windows 2000 published by Microsoft
Press.

Re: [ros-kernel] Ton-O-Bugs

[Jason F. <jas...@ya...>]

Hey Eric

>Could that by related to this IRQ-Level bug? I checked out the
>following sticky files:
>...

Very possibly yes! Most of the crashes occured somewhere in an ISR of
a driver.

>Using these file releases makes ReactOS run stable on my machine.

So it's a known IRQ bug? Can you tell me any more about it?

>Btw, I'm currently replacing the hard-coded loading system boot
>drivers. They will soon be loaded according to the services list in
>the registry. This is one of the major showstoppers for booting
>ReactOS into an installation program.

I'm also glad to know that the registry has progressed to a point
where it can be used for something like that!

- Jason








__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[ros-kernel] CVS Commit: freeldr

[Brian P. <br...@sg...>]

Modified Files:
            CHANGELOG FREELDR.INI freeldr/Makefile freeldr/freeldr.h 
            freeldr/linux.c freeldr/linux.h freeldr/miscboot.c 
            freeldr/miscboot.h freeldr/multiboot.c freeldr/rules.mk 
            freeldr/arch/i386/Makefile freeldr/arch/i386/boot.S 
            freeldr/ui/tui.c 
Added Files:
            freeldr/version.c freeldr/version.h
freeldr/arch/i386/linux.S
 
Log Message:
 
Changes in v1.2 (4/30/2002)
 
- All Linux kernels are supported (zImage & bzImage, loaded high & low)
- Initrd support
- FreeLoader now compiles under Mingw32 instead of just DJGPP, but
  the Mingw32 linker seems to output a corrupt binary.

[ros-kernel] Re: File system struct - ENOUGH ALREADY

[Phillip S. <ps...@cf...>]

At 04:20 AM 4/30/2002 +0200, you wrote:
>Ah, and don't forget we aren't the only OS to have a POSIX subsystem, 
>still we are the only to question whether its root directory should match 
>the "system" root, whether /dev is visible to other subsystems, and so on. 
>Designers of MacOS/X had no doubt, apparently, and they solved the 
>"usability" issue (i.e. the user wondering what are all those strange 
>directories in the root) raised by some by just... hiding the POSIX 
>directories in the GUI. MacOS/X is a Unix you say? Partially true, but 
>BeOS wasn't at all. Still, also its POSIX subsystem accessed the same 
>namespace of native programs, and /dev was visible to all programs. One 
>wonders why those fools at Be and Apple decided so, given the elaborate 
>rationales the members of this project use to justify the opposite approach

They decided to do so because their entire systems were based on POSIX, our 
is not.  It is easy enough to use a single posix filesystem when the kernel 
and applications are all based on posix, it is not when the kernel and 
applications are based on NT.  Windows applications assume that there are 
drive letters, that files have extensions to indicate their type, and that 
they have an ACL, not a chmod mask.  Trying to run these apps on a posix 
filesystem requires dirty compromises - just look at WINE.  The issue here 
is not what the user sees in the gui, but what the applications see the 
filesystem as, and win32 apps expect to see a win32 type filesystem, not a 
posix one.  OSX and BeOS apps expect to see a posix filesystem, which is 
why they have no problems doing so.


>One more thing: NT is NOT a microkernel, so please stop considering it 
>such. It may make sense to have special filesystems (think /proc) 
>implemented by subsystems, ON A MICROKERNEL SYSTEM, that will surely 
>provide facilities to implement system calls as IPC calls. But, alas, NT 
>isn't, so it's just not going to work. At least, not to the extent you'd hope

This is something I have been asserting for a long time now, yes, NT is NOT 
a microkernel despite what MS says.   It is a modular kernel.  As for 
implementing /proc in the posix subsystem vs. the kernel, why should it be 
implemented in the kernel if it is only going to be seen by the posix 
subsystem?  It makes sense to me to just leave it in the posix subsystem in 
user space in that case.  If win32 and native apps could also see it, then 
sure, put it in the kernel, but I don't think you can do this, as /proc is 
a posix filesystem, and as mentioned above, win32 and NT native apps can't 
deal with posix filesystems.

Note that it is currently my opinion that the posix and win32 filesystems 
are too different to reconcile them ( without unacceptable sacrifices in 
functionality ), but if you think it can be done, then figure out how to do 
so, and implement it and/or explain how to the rest of us.  Who knows, 
maybe you can come up with a way to reconcile them, if so, I'd love to hear 
it.

If you are ever on irc, we could discuss this in #ReactOS.

Re: [ros-kernel] Re: File system struct - ENOUGH ALREADY

[KJK::Hyperion <no...@li...>]

At 02.14 30/04/2002, you wrote:
>I think you give up to easily. One problem is that you are trying to turn 
>ReactOS itself into a POSIX environment, instead of taking advantage of 
>the ReactOS subsystem abillity.

My point of view, which I won't try to defend any further (at least for a 
very long time), is to mix the best of all subsystems. The Win32 "standard" 
for filesystem structure is hardly the "best". Drive letters are hardly the 
best way to identify devices. Multiple roots are bad, they are the 
inheritance of an era (DOS) when there was no distinction between the 
operating system and the user interface, but we don't need them anymore

Ah, and don't forget we aren't the only OS to have a POSIX subsystem, still 
we are the only to question whether its root directory should match the 
"system" root, whether /dev is visible to other subsystems, and so on. 
Designers of MacOS/X had no doubt, apparently, and they solved the 
"usability" issue (i.e. the user wondering what are all those strange 
directories in the root) raised by some by just... hiding the POSIX 
directories in the GUI. MacOS/X is a Unix you say? Partially true, but BeOS 
wasn't at all. Still, also its POSIX subsystem accessed the same namespace 
of native programs, and /dev was visible to all programs. One wonders why 
those fools at Be and Apple decided so, given the elaborate rationales the 
members of this project use to justify the opposite approach

One more thing: NT is NOT a microkernel, so please stop considering it 
such. It may make sense to have special filesystems (think /proc) 
implemented by subsystems, ON A MICROKERNEL SYSTEM, that will surely 
provide facilities to implement system calls as IPC calls. But, alas, NT 
isn't, so it's just not going to work. At least, not to the extent you'd hope

[ros-kernel] Re: File system struct - ENOUGH ALREADY

[Casper H. <ch...@us...>]

> From: KJK::Hyperion <noog@li...>
> Re: File system struct - ENOUGH ALREADY  
> 2002-04-28 14:55
>
> At 18.59 28/04/2002, you wrote:
>
> Premise: I give up. Something must be terribly wrong with me. I try to
> be reasonable. I try to be understanding. I try to explain rationally
> my point of view. I try to bring real-world examples as proof of my
> design choices. 
> I try to come at compromises with your ideas. And it never works. So,
> I give up. Just do whatever you want, I won't waste my time anymore,
> because it just doesn't work. You all seem pretty smart guys, so I
> must be the problem
 
> Go ahead and be happy, the annoying troublemaker finally shut up. I'll
> never question whatever future choice of yours, this will be my last
> message

I think you give up to easily. One problem is that you are trying to
turn ReactOS itself into a POSIX environment, instead of taking
advantage of the ReactOS subsystem abillity. This is my major concern
when I happen to disagree with you. To my knowledge only two people are
working on the POSIX subsystem. You two probably have the most knowledge
of POSIX, so any design issues that only affects the POSIX subsystem and
POSIX applications, I do not (currently) care about. I may make
suggestions when I believe something could be done better, but since I'm
probably not going to implement them I won't be mad or even force you to
do it. Nor will any other developer on this list. You don't have to
implement what is suggested on this list. However, it may be that
someone disagrees with you and eventually provides a different
implementation of something you have implemented. If this is
unacceptable to you, the project coordinators may have to make a
decission about which implementation to keep.

If you think someone does not have good reasons for doing something a
specific way, then ask them to explain further. If you think you have
a better way of doing things, then prove the other developers wrong. 

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

Modified Files:
    lib/ntdll/rtl/registry.c
    ntoskrnl/cm/rtlfunc.c

Improved default value handling in RtlQueryRegistryValues().


Eric

Re: [ros-kernel] Ton-O-Bugs

[Casper H. <ch...@us...>]

man, 2002-04-29 kl. 16:41 skrev KJK::Hyperion:
>   - major flaw in our toolchain: GNU ld doesn't calculate the PE image 
> checksum, it just happily sets it to zero. Apparently no command line 
> switch controls this. NT refuses to load drivers with an incorrect checksum 
> (can't test the new Null driver because of this)

Actually, I would call this a missing feature instead since the PE image
checksum is optional. Anyways, a patch for binutils that provides PE
image checksum is submitted to the binutils project. The patch is
approved and applied to mainline CVS branch. This feature will be in the
next MinGW, expected to be released soon.

>   - GNU ld appears to ignore --entry if --subsystem is posix:
> 
> gcc -Wl,--base-file,base.tmp \
>   -Wl,--entry,_DllMain@12 \
>   -Wl,--file-alignment,0x20 -Wl,--section-alignment,0x20 
> -Wl,--subsystem,posix:19.90 -mdll -Wl,--image-base,0x400000 \
>   -o junk.tmp \
>   misc/psxx.coff misc/psxx.coff misc/main.o misc/stubs.o 
> ../../../../dk/w32/lib/ntdll.a
> 
> D:\devtools\mingw\bin\..\lib\gcc-lib\i386-mingw32\2.95.3-6\..\..\..\..\i386-mingw32\bin\ld.exe: 
> warning: cannot find entry symbol ___PosixProcessStartup; defaulting to 00400020

Possibly a bug in binutils. Submit a bugreport to the binutils project.
For details see their website.

Re: [ros-kernel] Ton-O-Bugs

[Eric K. <ek...@rz...>]

"Jason Filby" <jas...@ya...> wrote:


> Yes, please do commit them! I was actually just about to mail the
> list about my problems with the latest code...
>
> I can't get ReactOS, built from the latest code, to boot under Bochs.
> Has anyone else got it to work? It crashes in different places all
> the time. At first I thought it was the new disk driver stack, but
> using the old IDE driver also caused crashes.
>
> Anyone?

Could that by related to this IRQ-Level bug? I checked out the following
sticky files:
    hal/halx86/irql.c (release 1.2)
    ntoskrnl/ke/i386/irq.c  (release 1.17)
    ntoskrnl/ps/idle.c (release 1.14)

Using these file releases makes ReactOS run stable on my machine.

Btw, I'm currently replacing the hard-coded loading system boot drivers.
They will soon be loaded according to the services list in the registry.
This is one of the major showstoppers for booting ReactOS into an
installation program.

Eric

Re: [ros-kernel] Ton-O-Bugs

[Jason F. <jas...@ya...>]

Yes, please do commit them! I was actually just about to mail the
list about my problems with the latest code...

I can't get ReactOS, built from the latest code, to boot under Bochs.
Has anyone else got it to work? It crashes in different places all
the time. At first I thought it was the new disk driver stack, but
using the old IDE driver also caused crashes.

Anyone?

- Jason

--- "KJK::Hyperion" <no...@li...> wrote:
> It's amazing how many bugs one can find in a single morning without
> even 
> looking for them specifically (can I commit the fixes? or do you
> want to 
> review them first?):
>   - reactos/tools/helper.mk places TARGET_LFLAGS *before* default
> linker 
> flags in the command lines for kernel-mode targets, so it isn't
> possible to 
> override, for example, image and section alignment values (SOLVED:
> fixed 
> the affected rules)
>   - reactos/tools/helper.mk doesn't define the "nostrip" rule for
> static 
> library targets (SOLVED: added a dummy rule, line marked with a
> FIXME comment)
>   - the Null device driver (reactos/services/dd/null) has a couple
> of bugs 
> in the entry point routine (SOLVED: bugs fixed. Null driver now
> also 
> manages a "zero stream" device. Two at the price of one)
>   - major flaw in our toolchain: GNU ld doesn't calculate the PE
> image 
> checksum, it just happily sets it to zero. Apparently no command
> line 
> switch controls this. NT refuses to load drivers with an incorrect
> checksum 
> (can't test the new Null driver because of this)
>   - GNU ld appears to ignore --entry if --subsystem is posix:
> 
> gcc -Wl,--base-file,base.tmp \
>   -Wl,--entry,_DllMain@12 \
>   -Wl,--file-alignment,0x20 -Wl,--section-alignment,0x20 
> -Wl,--subsystem,posix:19.90 -mdll -Wl,--image-base,0x400000 \
>   -o junk.tmp \
>   misc/psxx.coff misc/psxx.coff misc/main.o misc/stubs.o 
> ../../../../dk/w32/lib/ntdll.a
> 
>
D:\devtools\mingw\bin\..\lib\gcc-lib\i386-mingw32\2.95.3-6\..\..\..\..\i386-mingw32\bin\ld.exe:
> 
> warning: cannot find entry symbol ___PosixProcessStartup;
> defaulting to 00400020
> 
> 
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[ros-kernel] Ton-O-Bugs

[KJK::Hyperion <no...@li...>]

It's amazing how many bugs one can find in a single morning without even 
looking for them specifically (can I commit the fixes? or do you want to 
review them first?):
  - reactos/tools/helper.mk places TARGET_LFLAGS *before* default linker 
flags in the command lines for kernel-mode targets, so it isn't possible to 
override, for example, image and section alignment values (SOLVED: fixed 
the affected rules)
  - reactos/tools/helper.mk doesn't define the "nostrip" rule for static 
library targets (SOLVED: added a dummy rule, line marked with a FIXME comment)
  - the Null device driver (reactos/services/dd/null) has a couple of bugs 
in the entry point routine (SOLVED: bugs fixed. Null driver now also 
manages a "zero stream" device. Two at the price of one)
  - major flaw in our toolchain: GNU ld doesn't calculate the PE image 
checksum, it just happily sets it to zero. Apparently no command line 
switch controls this. NT refuses to load drivers with an incorrect checksum 
(can't test the new Null driver because of this)
  - GNU ld appears to ignore --entry if --subsystem is posix:

gcc -Wl,--base-file,base.tmp \
  -Wl,--entry,_DllMain@12 \
  -Wl,--file-alignment,0x20 -Wl,--section-alignment,0x20 
-Wl,--subsystem,posix:19.90 -mdll -Wl,--image-base,0x400000 \
  -o junk.tmp \
  misc/psxx.coff misc/psxx.coff misc/main.o misc/stubs.o 
../../../../dk/w32/lib/ntdll.a

D:\devtools\mingw\bin\..\lib\gcc-lib\i386-mingw32\2.95.3-6\..\..\..\..\i386-mingw32\bin\ld.exe: 
warning: cannot find entry symbol ___PosixProcessStartup; defaulting to 00400020

[ros-kernel] WARNING! Isoboot seems to be able to damage the flash bios!!

[Eric K. <ek...@rz...>]

Hi!

This is no joke! :-(
Yesterday I tried isoboot on my 'other' machines. It seemed to work pretty
well on my noteboot so I wanted to try two other machines. After the 'Press
any key to boot from CD' message the machines seemed to be frozen and I
pressed the reset button. In both cases the bios was damaged.

The MSI (MicroStar) K7T Turbo (MS-6330 V3.0), which does NOT a have a bios
protection jumper, seems to be almost entirely dead. The other machine is an
ECS (Elitegroup) D6VAA 1.1 booted into the bios boot block and asked for a
boot disk to reflash the bios. The ECS board has a bios protection jumper,
but of course it is diabled by default. After reflashing the ECS board it
seems to be okay again.

I just ordered a 'bios saver' which will allow to switch between the
original bios and a backup bios. This way I hope to get the MSI board
working again.

At present I'm trying to find out why isoboot fails to run freeldr and why
the bios gets damaged. Please don't use isoboot until further notice! If you
ignore my advice, don't come to me crying that isoboot ate your bios.


See you,
Eric

RE: [ros-kernel] Possible licensing issues?

[Steven E. <Ste...@ya...>]

> I don't agree with this. IMO the whole ReactOS-project should 
> be GPL'd. The author of a driver, dll or utility is always 
> free to relicense his code to the Wine project under the LGPL 
> or X11 license.

I agree with that, but I think we should encorage developers to 
license there code under BSD/LGPL if it is needed for the wine/rewind
Projects.

Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

[ros-kernel] CVS Commit: reactos

[Hartmut B. <har...@te...>]

lib\msvcrt\misc\dllmain.c:
Added _fcloseall for DLL_PROCESS_DETACH.

lib\msvcrt\sys_stat\fstat.c:
Added S_IFREG for files only.

lib\msvcrt\misc\getargs.c:
Added wild card expansion for argv.

- Hartmut

Re: [ros-kernel] File system struct - ENOUGH ALREADY

[KJK::Hyperion <no...@li...>]

At 18.59 28/04/2002, you wrote:

Premise: I give up. Something must be terribly wrong with me. I try to be 
reasonable. I try to be understanding. I try to explain rationally my point 
of view. I try to bring real-world examples as proof of my design choices. 
I try to come at compromises with your ideas. And it never works. So, I 
give up. Just do whatever you want, I won't waste my time anymore, because 
it just doesn't work. You all seem pretty smart guys, so I must be the problem

Go ahead and be happy, the annoying troublemaker finally shut up. I'll 
never question whatever future choice of yours, this will be my last message

> > what about paths starting with one or two (back-)slashes? I think
> > those, as far as possible, should be portable, that is translate to
> > the same path in all subsystems. It's the only way we can guarantee
> > interoperability
>To guarantee interoperability you'd better use absolute system path names, 
>but they use the backslash as element separator, which forces you to 
>escape it, for instance in PSX shells.

POSIX+, as an extension to the standard, accepts backslashes as path 
separators (backslash isn't in the portable filename character set, so this 
should be ok). They still need to be escaped wherever the backslash is a 
special character (shell commands, C code, etc.). The negative effects can 
be mitigated by appropriate good programming practices, like enclosing 
paths for shell commands in single quotes to avoid any kind of special 
interpretation of characters

A possible alternative approach is using the forward slash for Win32/DOS 
wherever possible in the user interface

> > >For the PSX subsystem, we could define that "/dev/x" will be
> > >translated by PSXDLL.DLL into "\POSIX+\SYSTEM\x" and PSXSS.EXE, at
> > >initialization time, will create symbolic links in "\POSIX+\SYSTEM"
> > >to real devices.
> > if it's not a real directory it shouldn't appear like a real
> > directory. Until we have a filesystem that can host a true /dev
> > directory, better use a double-slash path for such virtual
> > directories, like //./dev/ or similar. The Single Unix Specification
> > (SUS) as of version 3 allows double-slash paths with
> > implementation-specific meaning, and Win32 accepts double-slash paths
> > too. /dev in itself is not defined by the SUS, it is by Filesystem
> > Hierarchy Standard (FHS), but we're far from being able to implement
> > it fully anyway
>Since open() and fopen() are implemented in the PSX client library 
>(PSXDLL.DLL) you do NOT need a file system to implement dev, proc etc name 
>spaces.

Many /proc objects have been created with the sole purpose of being passed 
as pathnames to programs, to allow programs to access stuff they couldn't 
normally access. Having /proc implemented locally in POSIX+ kind of defeats 
its whole purpose. For example, a common /proc trick is passing to some 
program a pathname of /proc/self/fd/1 to force it to write on the standard 
output. Think of most Win32 programs, even many command line utilities have 
this limitation

RE: [ros-kernel] Status of building Wine under Cygwin/Mingw

[Robert C. <rob...@it...>]

> -----Original Message-----
> From: Francois Gouget [mailto:fg...@fr...]=20
> Sent: Monday, April 29, 2002 6:15 AM
> To: Robert Collins
> Cc: Ste...@ya...; win...@wi...; ReactOS-Kernel
> Subject: RE: [ros-kernel] Status of building Wine under Cygwin/Mingw
>=20
>=20
> On Sun, 28 Apr 2002, Robert Collins wrote:
> [...]
> > > 4. add -liberty to the makefile for wrc and wmc. This is needed=20
> > > because of getopt and optarg
> >
> > Cygwin has a BSD licenced getopt.c that doesn't need libiberty to=20
> > link, only mingw (AFAIK). Anyway worth investigating?
>=20
>    I usually regard getopt functions as higly unportable and=20
> always try to avoid them. I did not check how they are used=20
> in wrc&co, but it should not be very difficult to do entirely=20
> without them. I believe that would be the best solution.

You must end up writing the same bit of code many times. Ahh well, have
fun.

Rob