Samuel serapion wrote:
> looks like spam... from what little i understand of it
>
Please have the decency not to re-include the entire 10KB html email and
to add your own 6KB 1-line reply.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hi. I have two questions:
1) Do we still use DECLARE_RETURN\CLEANUP macros, or it is obsolete and
shouldn't be used any more? Why not use goto directly?
2) Do we still use MmCopyFromCaller\MmCopyToCaller or not? (I heared the
new standart is to use probing macros and SEH )
> "Neither UNTFS.DLL nor UFAT.DLL call file system drivers to take any
part in a format or chkdsk operation - they directly read and write raw
clusters on the drive."
That's why you have to unmount the drive when ie. formatting or chkdsk'ing
it. Defragmentation however can be done whithout unmounting, because the
fs driver handles this job. The IOCTLs are documented in the platform sdk,
defragmentation really doesn't work using fmifs/ufat/untfs/u...
- Thomas
>From the sysinternals website that is somewhat involved with microsoft:
"Neither UNTFS.DLL nor UFAT.DLL call file system drivers to take any part in a format or chkdsk operation - they directly read and write raw clusters on the drive."
Imre
>-----Original Message-----
>From: Thomas Weidenmueller [mailto:w3seek@reactos.com]
>Sent: Monday, September 4, 2006 03:42 PM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] Command line
>
>
>> The big benefit of using this library is that it let's you write code to
>> manipulate the FAT file system that works on FAT12, FAT16, FAT32 without
>> knowing the exact FAT file system this is going to run on. The same code
>> works for FAT12, FAT16, FAT32 without having code that looks like:
>
>In ROS each FS driver has to implement the defrag APIs. An application can
>defrag any FS by using the 3 publicly documented IOCTLs.
>UFAT/UNTFS/Uxxx... is not used for fs defragmentation.
>
>> Anyway this could be used as the basis for ufat.dll. The utilities that
>> already use this library could then also be put in here. And the rest can
>> then be easily written.
>
>As mentioned above, defragmentation is done by the fs drivers in kernel mode.
>
>> What would then be needed is the actual functions that make up the
>> interface to ufat.dll.
>
>We can design the interfaces to ufat, untfs, ... as we wish. These
>interfaces are not documented publicly as there is no standard. each FS
>should come with it's own utilities. Chkdsk can only be used with the file
>systems that come with windows/reactos, other FS need to provide their own
>tools.
>
>- Thomas
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
The current design of defrag, chkdsk, recover FAT manipulation utilities in FreeDOS is that there is a FAT manipulation library called the "FAT transformation engine" that all the other utilities use.
The big benefit of using this library is that it let's you write code to manipulate the FAT file system that works on FAT12, FAT16, FAT32 without knowing the exact FAT file system this is going to run on. The same code works for FAT12, FAT16, FAT32 without having code that looks like:
if it is FAT12 do this,
and if it is FAT16 do that
and if it is FAT32 do again something else.
Like is done in the reactos loader (freeloader?)
This is optimized code that is used in real life programs.
Anyway this could be used as the basis for ufat.dll. The utilities that already use this library could then also be put in here. And the rest can then be easily written.
What would then be needed is the actual functions that make up the interface to ufat.dll.
I've seen that there is example code on the internet that uses these functions. On http://www.sysinternals.com/SourceCode/fmifs.html
Imre
>-----Original Message-----
>From: Steven Edwards [mailto:winehacker@gmail.com]
>Sent: Monday, September 4, 2006 02:23 AM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] Command line
>
>On 9/3/06, Aleksey Bragin <aleksey(a)studiocerebral.com> wrote:
>> We are really in demand of a working check-disk utility, so I gladly
>> accept any correctly working version compatible with Windows (as in:
>> not depending on specific ReactOS's features).
>> It doesn't stop us from implementing fmifs.dll, uFILESYSTEM.dll's,
>> etc too. Even helps, I would say.
>
>Thats why I started porting the dosfsck a while back. Some of the
>lower level dlls for filesystem checking are highly obfuscated. It
>would be better to have a working tool now rather than never.
>
>
>--
>Steven Edwards
>
>"There is one thing stronger than all the armies in the world, and
>that is an idea whose time has come." - Victor Hugo
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> This needs to end, now!
*WE* would have to do something, not them. The credibility is quite low,
which is absolutely comprehensible. But that's not neccessary because I
believe it's already too late. I don't think the relationship to wine is
ever going to be the one it used to be again. Let's just live with it...
- Thomas
It seems that other people, from the FreeDOS site, are already working on the idea of making the FreeDOS utilities working as console applications on windows. There seems to be already a sourceforge project created.
But I don't want to anounce the work of somebody else too much. So I'll be quiet about the rest.
Making them available as windows console applications is probably best, that way they can be used in windows, reactos and FreeDOS (using the HX-DOS extender), exactly the same. People can then choose wether they want to use/bundle these with reactos.
Imre
>-----Original Message-----
>From: Brandon Turner [mailto:turnerb7@msu.edu]
>Sent: Sunday, September 3, 2006 05:58 PM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] Command line
>
>Imre Leber wrote:
>> A few hours ago the base part of FreeDOS version 1 was released.
>>
>> Now is probably a good time to port all the relevant FreeDOS commands: move, diskcopy, diskcomp, chkdsk, fc, ... to reactos.
>>
>> Some of them are written in assembly and would inherently not be portable (deltree, ...).
>>
>> Imre
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>>
>Well as long as windows has these application(and they have all the ones
>you mentioned excluding move which is internal to cmd) they can be moved
>to ReactOS\base\applications which is where we keep all these apps.
>Though, we might want to stay away from the asm ones. My question is
>whether we are going to do vendor drops and treat them like wine code
>where we sync them back all the time and submit patches back to the
>original project to get them when we sync again or whether we we are
>just going to add them to the our tree?
>
>Either way, I can probably help in the process to move them over.
>
>--
>Brandon Turner
>ReactOS Release Engineer
>Blog: http://www.amateurgramming.com
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
Hi
Open network control panel,,, I have a driver installed, I can see it with explorer ntobjs.
(dll/win32/shell32/classes.c:381) HCR_GetFolderAttributes should be called for simple PIDL's only!
(dll/win32/shell32/classes.c:381) HCR_GetFolderAttributes should be called for simple PIDL's only!
(dll/win32/powrprof/powrprof.c:318) (74AD0000, 1, 00000000) not fully implemented
(dll/win32/powrprof/powrprof.c:318) (74AD0000, 0, 00000000) not fully implemented
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app
(dll/win32/shell32/shellord.c:821) MRU processing failed, handle zero
(dll/win32/shell32/shlexec.c:1251) flags ignored: 0x00000004
(KERNEL32:dll/win32/kernel32/process/create.c:1098) Can't execute a DLL
(ntoskrnl/ps/process.c:692) FIX PS SDs!!
(ntoskrnl/ps/thread.c:503) FIX PS SDs!!
(ntoskrnl/ps/thread.c:503) FIX PS SDs!!
(dll/ntdll/ldr/utils.c:1194) LdrGetExportByName(): failed to find mxdMessage
(dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'msacm.drv' (Status c0000135)
(dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'midimap.drv' (Status c0000135)
(dll/cpl/ncpa/ncpa.c:103) EnumRegKeys: RegEnumKeyEx failed for ...ÿ (rc 0x103)
Thanks,
James
