Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] Command line
by Imre Leber 04 Sep '06

04 Sep '06

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 > >

1 0

Missing Network Info from CPL
by James Tabor 04 Sep '06

04 Sep '06

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

1 0

Re: [ros-dev] Command line
by Imre Leber 04 Sep '06

04 Sep '06

>-----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 > >

4 3

Re: [ros-dev] [ros-diffs] [ion] 23903: - Final cleanup for now: - main.c -> freeldr.c + cleanups and nice formatitng. - Move out variables that were in main.c to ex\init.c or cpu.c, depending. - Separate i386/kernel.c into i386/kiinit.c for X86-specific intiailization, and /krnlinit.c for portable initialization across all architectures. Also move out global variables appropriately. - main_asm.S -> cpu.S
by Alex Ionescu 03 Sep '06

03 Sep '06

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

2 1

Command line
by Imre Leber 03 Sep '06

03 Sep '06

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

3 2

Re: [ros-dev] wxwidgets
by Imre Leber 03 Sep '06

03 Sep '06

>-----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 > >

8 13

Re: [ros-dev] scope?
by Imre Leber 02 Sep '06

02 Sep '06

>-----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 > >

1 0

Re: [ros-dev] scope?
by Imre Leber 02 Sep '06

02 Sep '06

1 0

Re: [ros-dev] [ros-diffs] [greatlrd] 23826: 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
by Reuel ben Yisrael 02 Sep '06

02 Sep '06

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

5 8

Re: [ros-dev] scope?
by Imre Leber 02 Sep '06

02 Sep '06

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev