Hi all,
I think this is important to share to the discussion. From one of the developers
with FreeDOS, Eric Auer.
Thanks,
James
-------- Original Message --------
Subject: [Freedos-user] re: FAT and other file systems
Date: Fri, 13 Jan 2006 17:16:34 +0100 (MET)
From: Eric Auer <eric(a)coli.uni-sb.de>
Reply-To: freedos-user(a)lists.sourceforge.net
To: freedos-user(a)lists.sourceforge.net
Hi James,
> > And I think it is not more difficult to write HFS or FFS in the kernel
> > of FreeDOS than ReiserFS or XFS or all the other candidates.
I would like to comment this as follows: The Linux kernel modules for
ext3+jbd take 131+59k of memory. Reiserfs takes 243k (243*1000 bytes,
too lazy to convert to units of 1024 bytes). On the other hand, FAT
core takes 38k and you use it with either MSDOS (8k) or VFAT (13k)
implementations. Only the VFAT (long file name enabled) module of
Linux is affected by the 3 MS patents mentioned on the MS homepage.
> There is no way around this, unless someone will write a disclaimer, "Before
> you install FreeDos, do you want to enable Fat32 Patented Features"?
Microsoft WANTS you to believe that they patented FAT32.
Actually they patented their clever but twisted way to store
short and long filenames in the same directory, in a way which
allows LFN-unaware operating systems to use the drive without
getting confused by the LFN data and usually also without
damaging the LFN data either. But you already point that out yourself:
> We are
> facing the same issue with Ros. When I use FreeDos, I use the basic 8.3
> file system, so I don't see that as a major problem. The point here is the
> patent is about LFN, basic 8.3 is not effected.
So the disclaimer would only be displayed when you install the DOSLFN
package: "Install DOSLFN, which might have patent issues?". FreeDOS as
a DOS operating system itself is not affected by that problem. Plus
MS does have a disclaimer about their licensing, too:
http://www.microsoft.com/whdc/hwdev/download/hardware/fatgen103.pdf
which is more than 5 years old by now...
allows you to be compatible to all their FAT (including LFN) stuff
for the purpose of booting, OS installation, diagnosis, firmware,
similar things. They also tell that making/installing operating
systems may use all aspects of FAT. You could see this in a pessimist
way (you are allowed to develop and compile your OS on a LFN enabled
host system) or in a more optimistic way (your operating system
itself is allowed to use LFN because it simply is an operating system).
MS is targetting two groups at the moment: Vendors of USB sticks who
preinstall files on their sticks, and vendors of cams and mp3 players
and similar devices. FreeDOS is neither of those. But I did notice
that my hardware mp3 player does not support LFN. It only shows the
id3 text, if available, as "long song name", and is limited to
showing the SHORT file name as song name otherwise. Looks like
the vendor of the player did not want to pay MS for each device.
Digicams have similar issues - they usually generate filenames
like dsc0815 dot jpg and store all extra "title/name" information
inside the file (jpeg comment, EXIF data...?).
Eric
PS: I assume that you mean ReactOS, the free open WinNT clone,
when you mention Ros. ReactOS without LFN would not be the same...
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Freedos-user mailing list
Freedos-user(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
I'm reading reports of a US patent on FAT.
What's going on and how will this effect us?
The US patent rules are seriously out of control :(
Ged
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Another twist in the tale :
http://www.linux-watch.com/news/NS2809681376.html
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Hi,
I have manually made a compilation unit and a patch with a 1 line diff
for uuid+shell32 and took my build from 30+ secs down to 9 on gcc.
Alex reported a drop from 22 to 1 on msvc. We need to create a master
source file for each Wine dll like the one attached and add some hacks
for the errors that popup. I have not tested the resulting shell32.dll
but it should work the same. I do not think we can automate generation
of the compilation unit sources for the Wine code due to the hacks we
will need to add like in the attached file.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
I'm not able to install ros from the current trunk on real hardware. At
the end of the second stage setup I see a reset, which seems to be a
triple fault. After the reset, I'm again on the second stage setup.
- Hartmut
Hi,
After applying my user-mode callback patch, I sometimes see a bugcheck
caused by my debugging code. It seems that we do user-mode callbacks
with Kernel APCs disabled (just like we also did them with PreviousMode
== KernelMode, thank God that I had to "break" HEAD to find this huge
bug... but that's another story). The old code "worked" because it did
not check for this serious mistake. Normally, I've noticed that messages
are sent through co_IntSendMessage which is called with KernelApcDisable
== -1. That function calls some unlocking functions and then does the
Callback, which is called with KernelApcDisable == 0, which is good.
However, co_IntSendMessage is sometimes being called from
co_MsqPeekHardwareMessage.
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
WaitObjects[1] = MessageQueue->NewMessages;
WaitObjects[0] = &HardwareMessageQueueLock;
do
{
UserLeaveCo();
WaitStatus = KeWaitForMultipleObjects(2, WaitObjects, WaitAny,
UserRequest,
UserMode, FALSE, NULL, NULL);
UserEnterCo();
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
while (co_MsqDispatchOneSentMessage(MessageQueue))
{
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
}
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
}
while (NT_SUCCESS(WaitStatus) && STATUS_WAIT_0 != WaitStatus);
In this loop, the first KernelApcState is -1. After the wait, it becomes
-2. Now normally there is nothing to dispatch, so the function
continues, and the -2 later becomes a -3 after another lock, then
gradually goes down to -2, then back to -1. So the function enters with
-1 and exits with -1, which is normal. However, if the Message Queue
*does* have a message on it, then co_MsqDispatchOneSentMessage ends up
being called. Remember that after the wait we're now at -2. So that
function will then call co_IntSendMessage at -2, which will lower ir it
to -1 before the callback. But now the callback runs at -1, which means
Kernel APCs are disabled... so we bugcheck.
I have absolutely NO knowledge of Win32k Message Queues/MesssageSending,
but something defintely seems wrong to me here...can anyone help please?
Best regards,
Alex Ionescu
hbirr(a)svn.reactos.org wrote:
> - We cannot access the OwnerTable without locking the resource.
> - The shared waiters may wait also on the semaphore. It makes no sense to boost a waiting thread.
> - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost,
> possible the dispatcher lock is released but the thread block (WaitNext) isn't changed.
>
>
>
> Updated files:
> trunk/reactos/ntoskrnl/ex/resource.c
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
>
Oops, I've copied the wrong commit message. The correct is:
- We cannot access the OnerTable without locking the resource.
- The shared waiters may wait also on the semaphore. It makes no sence
to boost a waiting thread.
- The thread header is initialized like KeWaitForSingleObject (?, ?, ?,
TRUE, ?). During the boost,
possible the dispatcher lock is released but the thread block
(WaitNext) isn't changed.
- Hartmut
Hi all,
With real hardware and revision 20802, At the end of first stage and after hitting
the Finish button, I can reproduce this every time too,
KeBugCheck at ./ntoskrnl/mm/marea.c:901
A problem has been detected and ReactOS has been shut down to prevent damage to
your computer.
Technical information:
*** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000)
Frames:
<ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))>
<ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))>
<ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())>
<ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())>
<ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))>
<ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())>
<ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))>
<ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))>
<ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))>
<KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())>
Entered debugger on embedded INT3 at 0x0008:0x80073b86.
kdb:> bt
Eip:
<ntoskrnl.exe:73b87 (lib/rtl/i386/debug_asm.S:28 (DbgBreakPointWithStatus))>
Frames:
<ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))>
<ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))>
<ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())>
<ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())>
<ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))>
<ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())>
<ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))>
<ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))>
<ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))>
<KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())>
<winlogon.exe:1ae2>
<winlogon.exe:20f6>
<winlogon.exe:339a>
<winlogon.exe:11e7>
<winlogon.exe:1258>
<00000000>
kdb:>
I go into ntoskrnl/mm/marea.c and at line 891 I change DPRINT to DPRINT1, now
the system reboots and runs normal. I even have Abiword running with Winefile.
Thanks,
James
hbirr(a)svn.reactos.org wrote:
> if (!Resource->ActiveCount)
> {
>
>
>- /* Nobody owns it, so let's take control */
>
>
>+ if (Resource->NumberOfSharedWaiters == 0)
>+ {
>+ Owner = &Resource->OwnerThreads[1];
>+ }
>+ else
>+ {
>+ /* Find a free entry */
>+ Owner = ExpFindFreeEntry(Resource, &OldIrql);
>+ if (!Owner) goto TryAcquire;
>+ }
>+
>+ Owner->OwnerThread = Thread;
>+ Owner->OwnerCount = 1;
>
>
> Resource->ActiveCount = 1;
>
>
>- Resource->OwnerThreads[1].OwnerThread = Thread;
>- Resource->OwnerThreads[1].OwnerCount = 1;
>
>
>
> /* Release the lock and return */
> ExReleaseResourceLock(&Resource->SpinLock, OldIrql);
>
>
This change makes no sense. Note that we check for
!Resource->ActiveCount. This, by definition implies that there CANNOT be
any exclusive owner or shared owner. Access to the resource should be
granted instanteously.
Best regards,
Alex Ionescu