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
>-----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.
>
Some of them I personally maintain, like diskcopy and chkdsk.
I would very much like to extend this maintenance into reactos. I actually would like to volunteer for all these other tools coming from FreeDOS too.
But then we do talk about fully 32/64 bit binaries that are fully aware of reactos.
You could build thess from scratch for the reactos project, but I think it would be much more productive to start from an already very stable code base. Instead of maybe again spending 12 years of development.
Imre
>--
>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
>
>
ion(a)svn.reactos.org wrote:
> Author: ion
> Date: Mon Sep 4 01:06:30 2006
> New Revision: 23903
> - main_asm.S -> cpu.S
That should've said -> boot.S. (as the change was actually done).
Art, hopefully this should've all made your PPC stuff a bit easier to
pan out architecturally in the kernel.
These changes also made NTLDR compatibility a lot more possible (but
still far away), since FREELDR-specific bootstrapping is now completely
isolated (except 1 thing which will be deprecated soon enough).
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
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
>-----Original Message-----
>From: Thomas Weidenmueller [mailto:w3seek@reactos.com]
>Sent: Friday, September 1, 2006 01:01 PM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] wxwidgets
>
>> What is the standpoint of the reactos project on using libraries, like for
>> example wxwidgets for implementing reactos software (like reactos movie
>> maker)?
>
>This would just make the build process more complicated than neccessary,
>and increase compile time and download size (sources). Tools/Applications
>that come with ReactOS are not needed and expected to be ported to other
>architectures. We should stick to plain Win32/64 APIs. Also C is preferred
>over C++ a lot.
>
>> Further is there any specification that says for example "everything has
>> to be compilable with mingw", or "everything has to run on i386/pentium
>> xx"?
>
>- No other tools/libraries neccessary on the host than the minimum build
>system (mingw, nasm, make)
>- Only use C++ when it makes sense, prefer C (not just because g++ is so
>extremely slow)
>- Don't include pre-built binaries in the repository, everything needs to
>be built from source code
>- Don't bloat the repository with tons of huge libraries (do we still have
>more than one xml library?!)
>- Software that is included in the base repository should not use
>frameworks for portability and use the APIs directly instead
>
>That's my personal opinions and doesn't neccessarily match with those of
>the other developers.
>
Of course, I was suggesting wxWidgets since it seems that it is the closest thing to MFC, what most windows programmers would be accustomed to.
That it also happens to run in linux is, of course, completely irrelevant.
Imre
>- Thomas
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>-----Original Message-----
>From: Steven Edwards [mailto:winehacker@gmail.com]
>Sent: Saturday, September 2, 2006 10:10 AM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] scope?
>
>On 9/1/06, James Tabor
><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote:
>
>> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/
>
>This could use some love. Tamlin fixed the reading code but the write
>code needs to be turned on and checked.
>
Actually, come to think of it. If dosfsck can be made to work reliably in reactos then FreeDOS chkdsk, which I wrote, should be portable to reactos, just by recompiling and rearanging some files.
This is because i used the io.c file from dosfsck to port chkdsk to linux.
And that also means that defrag can be recompiled the same way, since it is the same FAT manipulation code. Then only a windows interface would be needed!
Actually i think I am going to add a method to defrag, that pretty much does what windows does (I think):
move through the directories, and for every file that is fragmented, move it to a space where it can be store unfragmented.
You could do this a number of times until a fixpoint is reached or a fixed number of times. And if you keep this up as long as defrag is running. You could build a defrag that automatically keeps all your files defragmented (as far as possible).
If you want to do a full defragmentation then, maybe once a year, you would have to arrange it so that the drive became locked for the duration of the defragmentation.
Imre
>--
>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
>
>
>-----Original Message-----
>From: Steven Edwards [mailto:winehacker@gmail.com]
>Sent: Saturday, September 2, 2006 10:10 AM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] scope?
>
>On 9/1/06, James Tabor
><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote:
>
>> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/
>
>This could use some love. Tamlin fixed the reading code but the write
>code needs to be turned on and checked.
>
This is very old code! There is DOSFSCK 2.11 now.
It contains certain bugs that realy should require updating to the latest version.
Imre
>--
>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
>
>
greatlrd(a)svn.reactos.org wrote:
>Author: greatlrd
>Date: Thu Aug 31 01:17:53 2006
>New Revision: 23826
>
>URL: http://svn.reactos.org/svn/reactos?rev=23826&view=rev
>Log:
>Wrote RtlUshotByteSwap RtlUlongByteSwap and RtlUlonglongByteSwap to asm code.
> but we need a C api for header to linking it right. Put the asm version to i386
>
>
sure there must be away to avoid this double-function-call overhead?
>+.globl _UlongByteSwap
>+
>+.intel_syntax noprefix
>+
>+/* FUNCTIONS ***************************************************************/
>+
>+_UlongByteSwap:
>+ push ebp // save base
>+ mov ebp,esp // move stack to base
>+ mov eax,[ebp+8] // load the ULONG
>+ bswap eax // swap the ULONG
>+ pop ebp // restore the base
>+ ret
>
>
this should work:
_UlongByteSwap:
mov eax,[esp+8] // load the ULONG
bswap eax // swap the ULONG
ret
>+.globl _UlonglongByteSwap
>+
>+.intel_syntax noprefix
>+
>+/* FUNCTIONS ***************************************************************/
>+
>+_UlonglongByteSwap:
>+ push ebp // save base
>+ mov ebp,esp // move stack to base
>+ mov edx,[ebp+8] // load the higher part of ULONGLONG
>+ mov eax,[ebp+12] // load the lower part of ULONGLONG
>+ bswap edx // swap the higher part
>+ bswap eax // swap the lower part
>+ pop ebp // restore the base
>+ ret
>
>
_UlonglongByteSwap:
mov edx,[esp+8] // load the higher part of ULONGLONG
mov eax,[esp+12] // load the lower part of ULONGLONG
bswap edx // swap the higher part
bswap eax // swap the lower part
ret
>+_UshortByteSwap:
>+ push ebp // save base
>+ mov ebp,esp // move stack to base
>+ mov eax,[ebp+8] // load the USHORT
>+ bswap eax // swap the USHORT, xchg is slow so we use bswap with rol
>+ rol eax,16 // make it USHORT
>+ pop ebp // restore the base
>+ ret
>
>
_UshortByteSwap:
mov eax,[esp+8] // load the USHORT
bswap eax // swap the USHORT, xchg is slow so we use bswap with rol
rol eax,16 // make it USHORT
ret
or to save a byte...
_UshortByteSwap:
mov ebx,[esp+8] // load the USHORT
mov al, bh
mov ah, bl
ret
>-----Original Message-----
>From: Steven Edwards [mailto:winehacker@gmail.com]
>Sent: Saturday, September 2, 2006 10:10 AM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] scope?
>
>On 9/1/06, James Tabor
><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote:
>
>> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/
>
>This could use some love. Tamlin fixed the reading code but the write
>code needs to be turned on and checked.
>
Maybe I should take a look then, I already once ported this to FreeDOS (not MSDOS)
<small>it didn't work in MSDOS so Eric, from the other list didn't like it, so its his version that is in FreeDOS version 1</small>,
so I know exactly what should be done (it's changing io.c and then it should work).
Still it only works for FAT, not NTFS.
Imre
>--
>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
>
>
Well, the reason I ask is that i am also maintaining a defrag utility.
It currently does FAT12, FAT16, FAT32. But it would most likely not be so difficult to change it so that it can use the reactos calls for manipulating the file system. So it also works with NTFS.
It has a lot more functionality then is available in windows defrag. Like sorting directories, which I think is not possible in windows. And 5 methods of defragmenting drives.
A new interface should also be easy to add. There have always been two interfaces. So the all the file system manipulation code is completely seperate.
The defragmentation code already works in windows xp, on image files, because that is how i debug it with visual C++ 7.1.
So, you can tell me wether this would be of interest to reactos.
Imre
>-----Original Message-----
>From: Imre Leber [mailto:imre.leber@telenet.be]
>Sent: Thursday, August 31, 2006 10:24 AM
>To: ros-dev(a)reactos.org
>Subject: [ros-dev] scope?
>
>What is actually the scope of the reactos project?
>
>Just being able to run windows drivers and apps, or "everything that was on the CD" (like FreeDOS)?
>
>Imre
>
>
>
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
