Ros-dev September 2006

ros-dev@reactos.org

23 participants
31 discussions

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

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

02 Sep '06

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

4 4

PATCH - 64bit clean cabman (mostly)
by Steven Edwards 01 Sep '06

01 Sep '06

With this patch I can now build ReactOS with 64bit host gcc and not need the -m32 switch. I also tested with a 32bit gcc and cabinets still build and work properly in usetup. If someone has a better suggestion of how to fix this, please fix it. =) -- 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

3 2

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

01 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. > This seams reasonable. This should then be put in a specification of some sort and put on the web site. So everyone knows what they have to keep themselves to. Imre >- Thomas > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev September 2006