reactos-kernel

Re: [ros-kernel] Re: CVS changes

[Robert K. <ro...@ko...>]

>

That matches my imagination. - It's a driver!
However I want to add an Idea: It would be just consequent to mix gdi32 and
user32.dll
to win32k.dll which interfaces with .sys. The original gdi32 and user23.dll
will then just delegate
the calls. I imagine a ...systm%\NATIVE directory.
To advapi32 and kernel32.dll: I think they belong more to win32 than to
native.

>
>
> I have one more suggestion. Move subsys/win32k to drivers/win32k. It is
> unique in that it is the only mediator between display drivers and
> applications.
>
> - Casper
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] Re: CVS changes

[Robert K. <ro...@ko...>]

So do I. And I prefer to have core win32 components as native or at least in
the ROS module.

KJK::Hyperion schrieb:

> At 00.27 02/06/2002, you wrote:
> >Oh wait, yes we decided that there won't be a win32 module.
> >Everything that says move to win32 module stays in the reactos module.
>
> Win32 will gradually become larger and larger, much bigger than the kernel,
> possibly the biggest open source project on earth (download the Platform
> SDK help, or browse the MSDN library to get an idea of the amount of work
> that needs to be done). With a lot of code that does in no way belong to a
> kernel. Superfluous code, for people interested just in the kernel (e.g. to
> create an embedded version, or a completely different operating system
> based on the same kernel)
>
> I vote for a separate module
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

[ros-kernel] Designing modules

[Jarmo M. <jm...@ho...>]

Hello,

I've been reading this list for a while. I thought that I could
comment about designing.

I learned UML two weeks ago and now I am trying different UML CASE
tools. Enterprise Architect is the best one I've tried so far. I
drew two versions of ROS modules. One version is based on the idea
that every supported subsystem (Win32, OS/2, Posix, etc) has its
own module. Other version which doesn't have Win32 subsystem.

If Win32 is in its own module, this means that gdi32.dll,
kernel32.dll, user32.dll and others would be very thin. They just
call functions in ROS kernel module. Usually just calling
equivalent function in kernel. This would add small overhead to
every Win32 API call. For example

int MessageBox( ... )
{
 return RosMessageBox( ... );
}

RosMessageBox would do the hard work (my imaginary name for the
function). ROS functions should be compatible with Win32 API
because of the speed i.e. the parameters and return values should
be the same as in the same Win32 function. Some APIs could be
changed for simplicity and for other issues such as better
supporting other OSes.

The OS/2 subsystem would call the same function(s) in kernel.

int WinMessageBox( ... )
{
 // translate parameters before the call

 int result = RosMessageBox( ... );

 // translate result

 return result;
}

Remember to map error codes!

I understand that the above idea is dropped. Files like user32.dll
are moved to ReactOS kernel module. Win32 applications calls the
function as usual, but now the user32.dll does the hard work. OS/2
application links with their usual libs, but the libs calls
user32.dll and such. This approach might be a problem for some
APIs.

int WinMessageBox( ... )
{
 // translate parameters before the call

 // call user32.dll
 int result = MessageBox( ... );

 // translate result and map error code

 return result;
}

Both designs has their advantages and disadvatages. Anyway, I
think that the Win32 module includes is better one. It has more
capacity to get better. NT has layers in which API calls lower
level and which may call lower level. Does it actually hurt so
much if there is an extra level which does so little? But on the
other hand, you get more speed to Win32 apps if user32.dll etc
does the job without extra call.

Attached is both of the designs.

JMu

Re: [ros-kernel] native vs. Win32 - again

[Robert K. <ro...@ko...>]

My intend is to use just the naked windows from USer32. Other things like controls
need a reimplementation since they use different window messages.
this implies that the controls may look as one likes.

Yuri Prokushev schrieb:

> On Fri, 31 May 2002 11:36:50 +0100, Nick Date wrote:
>
> >> > OS/2 has its own graphics and windowing API: why should it use Win32?
> >
> >> it should at least use win32 windows and messages - that way you can
> >> run win32 and os/2 stuff on one desktop.
> >> getting them on one desktop with two distinct "window lists" (or however
> >they
> >> are stored internally) you'll have a big time trying to keep them all
> >> up-to-date...
> >I see where you're coming from here. I'm wondering how much of win32 it
> >would be feasable to strip from ReactOS if the user only wants to run OS/2
> >apps (save some space on your 40 gig hard disk :-] ).
> Why I need storage space for unused things?
>
> > It seems to me that in
> >order to do this you'd have to go back to the kernel and write an OS/2
> >GDI/GUI, but wouldn't this be a seperate project from OS/2 binary
> >compatibility?
> Who needs binary compatibility without APIs?
>
> GDI implemented by win32k. Isn't it? So all OS/2 GPI (=GDI) can be easely implemented like gdi32.dll (pmgpi in os2). Highlevel objects (user32.dll in win32) can be just
> copied (for common object like editfield). For other controls (like spinbuttons) code must be written from the scratch. So I don't see any reason for implement pmgpi via
> gdi32 instead of direct implementation via win32k.
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] native vs. Win32 - again

[Robert K. <ro...@ko...>]

>
> You should be able to use GDI32 and USER32 they make
> the needed calls to win32k.sys for Windowing.

OK, but who manages the actual windows or the frame windows.
I made the observation that if an app blocks, the frame window still
works.
This matches also that windows opened by a killed app, are also wiped
away.
This would imply that csrss registers when an app starts and which win
belongs
to it, in order to be able to remove it possibly.

This question may also be an answer to Yuri's complaints about "what is a
ss?
just a wrapper or even more". A sub system is the place where information
can be stored over processes or between systemcalls.

>
>
> Thanks
> Steven
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] Re: CVS changes

[Casper H. <ch...@us...>]

s=F8n, 2002-06-02 kl. 09:59 skrev Aliberti Emanuele:
> What about a compromise like this one: the win32 module won't be on=20
> its own module, but will replace the reactos/subsys subtree in the=20
> reactos module? I agreed with David that Win32 and NTOS are related,=20
> but I still like having any Win32 piece in a proper subtree and not=20
> scattered in the kernel module.

I have one more suggestion. Move subsys/win32k to drivers/win32k. It is
unique in that it is the only mediator between display drivers and
applications.

- Casper

Re: [ros-kernel] Re: CVS changes

[Casper H. <ch...@us...>]

s=F8n, 2002-06-02 kl. 00:24 skrev Jason Filby:
> Thanks Rex!
>=20
> Unfortunately, when running make I got the following error:
>=20
> make[1]: Entering directory `C:/ros/reactos/hal/halx86'
> gcc -g -o ../../tools/mkconfig ../../tools/mkconfig.c
> ../../tools/mkconfig ../../include/roscfg.h UP
> dlltool --as=3Das --dllname hal.dll \
>         --def ./../hal/hal.def \
>         --output-lib ./hal.a \
>         --kill-at
> make[1]: Leaving directory `C:/ros/reactos/hal/halx86'
> make -C services/bus/acpi implib
> make: *** services/bus/acpi: No such file or directory.  Stop.
> make: *** [acpi_implib] Error 2
>=20
> Is this due to the restructuring?
>=20
> Thanks
> - Jason

Should be fixed in CVS now.

- Casper

Re: [ros-kernel] Forward: "ReactOS is too limited"

[Casper H. <ch...@us...>]

s=F8n, 2002-06-02 kl. 19:56 skrev KJK::Hyperion:
> At 18.04 02/06/2002, you wrote:
> > > or copy \dev\zero A:. man CreateProcess. ssh -n foo WinWord.exe
> > > \\bar\usr\home\bill\baz.doc. The possibilities are endless.
> >Convince Microsoft that there are enough customers that would pay for=20
> >these featues.
>=20
> who cares what Microsoft does? we don't work for them

Sorry, I read it as a critisism of Microsoft not providing these
features.

- Casper

Re: [ros-kernel] Forward: "ReactOS is too limited"

[KJK::Hyperion <no...@li...>]

At 18.04 02/06/2002, you wrote:
> > or copy \dev\zero A:. man CreateProcess. ssh -n foo WinWord.exe
> > \\bar\usr\home\bill\baz.doc. The possibilities are endless.
>Convince Microsoft that there are enough customers that would pay for 
>these featues.

who cares what Microsoft does? we don't work for them

Re: [ros-kernel] bug in alloca ?

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	Casper Hornstrup [SMTP:ch...@us...]
> Gesendet am:	Freitag, 31. Mai 2002 17:40
> An:	rea...@li...
> Betreff:	Re: [ros-kernel] bug in alloca ?
>
> Could it be because our msvcrt headers define _alloca to use cdecl
> calling convention?

Alloca.h defines _alloca and alloca:

void * _alloca(size_t);
#define alloca(x) _alloca(x)

If alloca is removed or replaced with a real declaration, it works perfect. 
An other way is to replace alloca with _alloca in our source. Our alloca.h 
comes from mingw. Mingw has the same problem. Any comments?

- Hartmut

Re: [ros-kernel] Forward: "ReactOS is too limited"

[Casper H. <ch...@us...>]

s=F8n, 2002-06-02 kl. 15:40 skrev KJK::Hyperion:
> At 13.16 30/05/2002, you wrote:
> >type diskimage > \dev\fd0" why won't you let me?
>=20
> or copy \dev\zero A:. man CreateProcess. ssh -n foo WinWord.exe=20
> \\bar\usr\home\bill\baz.doc. The possibilities are endless.

Convince Microsoft that there are enough customers that would pay for
these featues.

> The last example is especially interesting: it starts Word on the remote =
machine foo=20
> through ssh, using the local display, opening a file from bill's home=20
> directory, on the remote machine bar, through SMB

Something similar can be accomplished with Windows XP's remote desktop.
You connect to foo from your client. You then get your desktop like you
would have logged on to foo locally.

- Casper

Re: [ros-kernel] Forward: "ReactOS is too limited"

[KJK::Hyperion <no...@li...>]

At 13.16 30/05/2002, you wrote:
>Cygwin would *almost* be an solution if win's console werent utterly 
>broken (by design). Please do not try to argue with me on that, repeat 
>after me, win's console (as it is implemented today in 2k) is UNUSABLE for 
>a command line power user. (Selection behaviour, size change restrictions 
>are the major showstoppers).

Not only from the user perspective, also from a programmer's point of view. 
The most important missing features are the slave-master model, and a 
single stream, for both data and control codes (the only advantage in using 
two separate streams is being able to print binary data... useless). Even 
DOS was better in this respect, when you could easily filter the console 
operations by simply hooking an interrupt, and embed ANSI codes in your 
batch files and printf strings for colored text and such

>I certainly wouldn't mind an open OS that can run M$-Ware, but if in that 
>OS the concious design decision is made that all apps developable for that 
>OS must also run under Windows - i.e. it is conciously limited in certain 
>areas - I certainly wonder about its usefulness. A "windows compatibility 
>certification mode" (or just "win32ss visible only mode"), maybe 
>per-process, would certainly be useful - but if I want to do "cmd.exe -c 
>type diskimage > \dev\fd0" why won't you let me?

or copy \dev\zero A:. man CreateProcess. ssh -n foo WinWord.exe 
\\bar\usr\home\bill\baz.doc. The possibilities are endless. The last 
example is especially interesting: it starts Word on the remote machine foo 
through ssh, using the local display, opening a file from bill's home 
directory, on the remote machine bar, through SMB

>BTW: If anyone feels like seriously thinking abouth some of these 
>'limitations' I could certainly flesh out a wishlist for 'doze from an 
>unix administrator's point of view.

I'm interested. I have a few in mind, but I want to hear the opinion of 
someone more experienced first

Re: [ros-kernel] Re: CVS changes

[Casper H. <ch...@us...>]

s=F8n, 2002-06-02 kl. 09:59 skrev Aliberti Emanuele:
> What about a compromise like this one: the win32 module won't be on=20
> its own module, but will replace the reactos/subsys subtree in the=20
> reactos module? I agreed with David that Win32 and NTOS are related,=20
> but I still like having any Win32 piece in a proper subtree and not=20
> scattered in the kernel module.

I agree.

- Casper

>=20
> On 1 Jun 2002 at 15:27, Jason Filby wrote:
>=20
> > Oh wait, yes we decided that there won't be a win32 module.
> > Everything that says move to win32 module stays in the reactos
> > module.
> >=20
> > Thanks
> > - Jason

Re: [ros-kernel] Forward: "ReactOS is too limited"

[KJK::Hyperion <no...@li...>]

At 06.11 31/05/2002, you wrote:
>P.S.: Further up in the thread it was said that the administrator can gain 
>'kill services' rights through some setting - anyone knows from the top of 
>their head which setting that is? Thanks!

the short answer: you need the SeDebug privilege
the long answer: NT security has the concept of capabilities/privileges. 
The Unix root user would be an user account with all privileges granted 
*and* enabled, while the NT Administrator merely has most privileges 
granted, but not enabled. Security-aware programs will enable the needed 
privileges first. Task manager, for example, doesn't. Good for normal 
users, bad for an admin. BTW, here are the privileges an Unix root user needs:

Privilege             Effect when enabled
----------------------------------------------------------------------------
SeBackup              bypass file and registry ACLs when writing data
SeRestore             bypass file and registry ACLs when reading data
SeDebug               bypass process and thread ACLs
SeTakeOwnership       bypass checks when taking ownership of an object
SeAssignPrimaryToken  ability to assign a process's primary token (Unix
                       "real user id" and "real group id")
SeLockMemory          ability to lock memory (i.e. make memory non-pageable)
SeSystemTime          ability to set system time
SeShutdown            ability to shutdown the local system
SeLoadDriver          ability to load device drivers
SeTcb                 ability to act as an operating system component

RE: [ros-kernel] Forward: "ReactOS is too limited"

[KJK::Hyperion <no...@li...>]

At 03.17 31/05/2002, you wrote:
>Also in this area of annoying niggles are `security' measures like 
>offering the administrator the option of disabling the Display control 
>panel, while leaving the programmatic interface to the thing unchecked.

I think we all agree that this sucks. It's because ACLs and objects (two 
building blocks of NT) haven't been used consistently by Microsoft. They 
preferred the registry-based advisory restrictions, the policies

>I honestly think that the DOS console model is too limited and broken to 
>make a decent terminal emulator program possible. The way to do it would 
>be to wrap it around the (greatly extended) POSIX subsystem, and ignore 
>the console entirely.

My idea, exactly. I'd even go as far as writing a kernel mode tty driver

>Zsh runs native in win32; it can be configured to be comfortable.

Win32 zsh is extremely buggy. It really suffers from the lack of an 
underlying POSIX runtime

Re: [ros-kernel] Re: CVS changes

[Casper H. <ch...@us...>]

s=F8n, 2002-06-02 kl. 11:59 skrev KJK::Hyperion:
> At 00.27 02/06/2002, you wrote:
> >Oh wait, yes we decided that there won't be a win32 module.
> >Everything that says move to win32 module stays in the reactos module.
>=20
> Win32 will gradually become larger and larger, much bigger than the kerne=
l,=20
> possibly the biggest open source project on earth (download the Platform=20
> SDK help, or browse the MSDN library to get an idea of the amount of work=
=20
> that needs to be done). With a lot of code that does in no way belong to =
a=20
> kernel. Superfluous code, for people interested just in the kernel (e.g. =
to=20
> create an embedded version, or a completely different operating system=20
> based on the same kernel)
>=20
> I vote for a separate module

Most of it will be a seperate module when we use WINE instead, but it
does not make sense to move them now because then we would have to
(re)move them again later.

- Casper

Re: [ros-kernel] Re: CVS changes

[KJK::Hyperion <no...@li...>]

At 00.27 02/06/2002, you wrote:
>Oh wait, yes we decided that there won't be a win32 module.
>Everything that says move to win32 module stays in the reactos module.

Win32 will gradually become larger and larger, much bigger than the kernel, 
possibly the biggest open source project on earth (download the Platform 
SDK help, or browse the MSDN library to get an idea of the amount of work 
that needs to be done). With a lot of code that does in no way belong to a 
kernel. Superfluous code, for people interested just in the kernel (e.g. to 
create an embedded version, or a completely different operating system 
based on the same kernel)

I vote for a separate module

Re: [ros-kernel] Re: CVS changes

[Aliberti E. <ea...@us...>]

What about a compromise like this one: the win32 module won't be on 
its own module, but will replace the reactos/subsys subtree in the 
reactos module? I agreed with David that Win32 and NTOS are related, 
but I still like having any Win32 piece in a proper subtree and not 
scattered in the kernel module.

On 1 Jun 2002 at 15:27, Jason Filby wrote:

> Oh wait, yes we decided that there won't be a win32 module.
> Everything that says move to win32 module stays in the reactos
> module.
> 
> Thanks
> - Jason
> 
> --- Rex Jolliff <re...@lv...> wrote:
> > 
> > For everyones benefit, I performed the following moves listed
> > below.
> > I sent a message to the list (or I thought I did) a few days ago.
> > But I realized after performing the moves that my alias in my mailer
> > does not point to the right place.  So, this is your heads up.  You
> > will need to checkout new working areas, as the ones you currently
> > have will have invalid directory paths in them.  Sorry for the
> > inconvienence.
> > 
> > At 02:02 PM 5/30/02 -0700, you wrote:
> > >Hey Rex
> > >
> > >Ok moving the files on the backend sounds great. Will you have
> > time
> > >to do it this weekend? It shouldn't take too long, if you're just
> > >moving directories, right? Here's what I have:
> > >
> > >In the reactos module:
> > >apps/*: removing apps/test, move apps/system to subsys
> > >everything then left in apps goes to apps/test
> > 
> > Done. I moved some of the apps to the utils directory insted of
> > tests dir. I renamed apps/test to apps/tests/test_old.
> > 
> > >new directory apps/utils (for utilities like objdir and partinfo)
> > 
> > Done.
> > 
> > >lib/bzip2: move to services/lib
> > 
> > Done.
> > 
> > >lib/crtdll: move to win32 module
> > 
> > module win32 does not exist. Do you want me to create one?  Since
> > the win32 subsystem is an integral part of the kernel, does it make
> > sense to move this to another module?
> > 
> > >lib/dflat32: move to rosapps module (?)
> > 
> > Done.  moved to rosapps/lib/dflat32.
> > 
> > >lib/fmifs: move to win32 module
> > >lib/msvcrt: move to win32 module
> > >lib/ole32: move to win32 module
> > >lib/oleaut32: move to win32 module
> > >lib/psapi: move to win32 module
> > >lib/shell32: move to win32 module
> > >lib/version: move to win32 module
> > 
> > See above question.
> > 
> > >lib/zlib: move to services/lib
> > 
> > Done.
> > 
> > >lib/ole: move to win32 module
> > >lib/ole32: move to win32 module
> > >lib/rpcrt4: move to win32 module
> > >lib/psapi: move to win32 module (?)
> > 
> > see about question.
> > 
> > >subsys/os2/*: move to os2 module
> > 
> > Done.
> > 
> > >subsys/psx/*: move to posix module
> > 
> > Done.
> > 
> > >move everything currently in services/ to drivers/
> > >then move rpcss, eventlog to services
> > 
> > Done.  rpcss and eventlog were not in the services directory
> > however, so I did nothing with them.
> > 
> > >Remove everything in the wine module except the makefiles
> > 
> > This is best done from cvs proper.  I will leave them for now.
> > 
> > 
> > Rex Jolliff
> > re...@lv...
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

RE: [ros-kernel] Re: CVS changes

[Steven E. <Ste...@ya...>]

> Why can't we use msvcrt and crtdll from WINE? Do the WINE 
> implementations use non-Win32 APIs?

Eric will may need to comment on this one also. 

From what I had gathered you should not just forward crtdll calls to
MSVCRT and that is what the wine crtdll does. I guess it could cause a
problem from some applications as crtdll is not supposed to be thread
safe and msvcrt is. MSVCRT under wine does you some non-win32 apis and
it has a few type conflicts with Mingw.

Thanks
Steven 

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

RE: [ros-kernel] Re: CVS changes

[Casper H. <ch...@us...>]

s=F8n, 2002-06-02 kl. 01:01 skrev Steven Edwards:
> Some of this stuff should stay in the ReactOS module but I though we
> were going to have a Win32/WINE module?=20

Yes, but maybe we should check if some DLLs need to be merged with the
WINE implementation.

>=20
> Msvcrt,fmifs,crtdll,advapi,user32,gdi32 is the code we CANNOT use from
> the WINE tree.=20

Why can't we use msvcrt and crtdll from WINE? Do the WINE
implementations use non-Win32 APIs?

- Casper

RE: [ros-kernel] Re: CVS changes

[Steven E. <Ste...@ya...>]

Some of this stuff should stay in the ReactOS module but I though we
were going to have a Win32/WINE module? 

Msvcrt,fmifs,crtdll,advapi,user32,gdi32 is the code we CANNOT use from
the WINE tree. 

These should be blown away and used from the WINE tree.
Ole32
Oleaut32
Paspi
Shell32
rpcrt4 

With the current WINE sources I can build these DLLS out of the Box:
comcat.dll
comctl32.dll
crtdll.dll (unusable for ReactOS as is just a forwarder to msvcrt)
crypt32.dll
dciman32.dll
dinput.dll
imagehlp.dll
imm32.dll
mapi32.dll
mpr.dll
msdmo.dll
msimg32.dll
msisys.ocx
netapi32.dll
odbc32.dll
oledlg.dll
olepro32.dll
rasapi32.dll
riched32.dll
serialui.dll
shdocvw.dll
tapi32.dll
twain_32.dll (fix those warnings)
urlmon
winnls.dll
winspool.dll
wintrust.dll


> Oh wait, yes we decided that there won't be a win32 module. 
> Everything that says move to win32 module stays in the reactos module.

> > >lib/fmifs: move to win32 module
> > >lib/msvcrt: move to win32 module
> > >lib/ole32: move to win32 module
> > >lib/oleaut32: move to win32 module
> > >lib/psapi: move to win32 module
> > >lib/shell32: move to win32 module
> > >lib/version: move to win32 module
> > >lib/ole: move to win32 module
> > >lib/ole32: move to win32 module
> > >lib/rpcrt4: move to win32 module
> > >lib/psapi: move to win32 module (?)



"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

RE: [ros-kernel] Re: CVS changes

[Steven E. <Ste...@ya...>]

> >lib/dflat32: move to rosapps module (?)
> 
> Done.  moved to rosapps/lib/dflat32.

You can blow this away compleately. Rosapps/edit has the same code that
actualy works, just not as a dll. I am not interested in trying to work
with it at this point.

Reactos/apps/tests can also be blown away. These were some tests I
ported from WINE and will no longer matter once we have the WINE
regression test suite.

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

[ros-kernel] Re: CVS changes

[Jason F. <jas...@ya...>]

Oh wait, yes we decided that there won't be a win32 module.
Everything that says move to win32 module stays in the reactos
module.

Thanks
- Jason

--- Rex Jolliff <re...@lv...> wrote:
> 
> For everyones benefit, I performed the following moves listed
> below.
> I sent a message to the list (or I thought I did) a few days ago. 
> But
> I realized after performing the moves that my alias in my mailer
> does
> not point to the right place.  So, this is your heads up.  You will
> need to checkout new working areas, as the ones you currently
> have will have invalid directory paths in them.  Sorry for the
> inconvienence.
> 
> At 02:02 PM 5/30/02 -0700, you wrote:
> >Hey Rex
> >
> >Ok moving the files on the backend sounds great. Will you have
> time
> >to do it this weekend? It shouldn't take too long, if you're just
> >moving directories, right? Here's what I have:
> >
> >In the reactos module:
> >apps/*: removing apps/test, move apps/system to subsys
> >everything then left in apps goes to apps/test
> 
> Done. I moved some of the apps to the utils directory insted of
> tests dir.
> I renamed apps/test to apps/tests/test_old.
> 
> >new directory apps/utils (for utilities like objdir and partinfo)
> 
> Done.
> 
> >lib/bzip2: move to services/lib
> 
> Done.
> 
> >lib/crtdll: move to win32 module
> 
> module win32 does not exist. Do you want me to create one?  Since
> the win32 subsystem is an integral part of the kernel, does it make
> sense to move this to another module?
> 
> >lib/dflat32: move to rosapps module (?)
> 
> Done.  moved to rosapps/lib/dflat32.
> 
> >lib/fmifs: move to win32 module
> >lib/msvcrt: move to win32 module
> >lib/ole32: move to win32 module
> >lib/oleaut32: move to win32 module
> >lib/psapi: move to win32 module
> >lib/shell32: move to win32 module
> >lib/version: move to win32 module
> 
> See above question.
> 
> >lib/zlib: move to services/lib
> 
> Done.
> 
> >lib/ole: move to win32 module
> >lib/ole32: move to win32 module
> >lib/rpcrt4: move to win32 module
> >lib/psapi: move to win32 module (?)
> 
> see about question.
> 
> >subsys/os2/*: move to os2 module
> 
> Done.
> 
> >subsys/psx/*: move to posix module
> 
> Done.
> 
> >move everything currently in services/ to drivers/
> >then move rpcss, eventlog to services
> 
> Done.  rpcss and eventlog were not in the services directory
> however, so I did nothing with them.
> 
> >Remove everything in the wine module except the makefiles
> 
> This is best done from cvs proper.  I will leave them for now.
> 
> 
> Rex Jolliff
> re...@lv...
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: [ros-kernel] Re: CVS changes

[Jason F. <jas...@ya...>]

Thanks Rex!

Unfortunately, when running make I got the following error:

make[1]: Entering directory `C:/ros/reactos/hal/halx86'
gcc -g -o ../../tools/mkconfig ../../tools/mkconfig.c
../../tools/mkconfig ../../include/roscfg.h UP
dlltool --as=as --dllname hal.dll \
        --def ./../hal/hal.def \
        --output-lib ./hal.a \
        --kill-at
make[1]: Leaving directory `C:/ros/reactos/hal/halx86'
make -C services/bus/acpi implib
make: *** services/bus/acpi: No such file or directory.  Stop.
make: *** [acpi_implib] Error 2

Is this due to the restructuring?

Thanks
- Jason

--- Rex Jolliff <re...@lv...> wrote:
> 
> For everyones benefit, I performed the following moves listed
> below.
> I sent a message to the list (or I thought I did) a few days ago. 
> But
> I realized after performing the moves that my alias in my mailer
> does
> not point to the right place.  So, this is your heads up.  You will
> need to checkout new working areas, as the ones you currently
> have will have invalid directory paths in them.  Sorry for the
> inconvienence.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[ros-kernel] Re: CVS changes

[Rex J. <re...@lv...>]

For everyones benefit, I performed the following moves listed below.
I sent a message to the list (or I thought I did) a few days ago.  But
I realized after performing the moves that my alias in my mailer does
not point to the right place.  So, this is your heads up.  You will
need to checkout new working areas, as the ones you currently
have will have invalid directory paths in them.  Sorry for the inconvienence.

At 02:02 PM 5/30/02 -0700, you wrote:
>Hey Rex
>
>Ok moving the files on the backend sounds great. Will you have time
>to do it this weekend? It shouldn't take too long, if you're just
>moving directories, right? Here's what I have:
>
>In the reactos module:
>apps/*: removing apps/test, move apps/system to subsys
>everything then left in apps goes to apps/test

Done. I moved some of the apps to the utils directory insted of tests dir.
I renamed apps/test to apps/tests/test_old.

>new directory apps/utils (for utilities like objdir and partinfo)

Done.

>lib/bzip2: move to services/lib

Done.

>lib/crtdll: move to win32 module

module win32 does not exist. Do you want me to create one?  Since
the win32 subsystem is an integral part of the kernel, does it make
sense to move this to another module?

>lib/dflat32: move to rosapps module (?)

Done.  moved to rosapps/lib/dflat32.

>lib/fmifs: move to win32 module
>lib/msvcrt: move to win32 module
>lib/ole32: move to win32 module
>lib/oleaut32: move to win32 module
>lib/psapi: move to win32 module
>lib/shell32: move to win32 module
>lib/version: move to win32 module

See above question.

>lib/zlib: move to services/lib

Done.

>lib/ole: move to win32 module
>lib/ole32: move to win32 module
>lib/rpcrt4: move to win32 module
>lib/psapi: move to win32 module (?)

see about question.

>subsys/os2/*: move to os2 module

Done.

>subsys/psx/*: move to posix module

Done.

>move everything currently in services/ to drivers/
>then move rpcss, eventlog to services

Done.  rpcss and eventlog were not in the services directory
however, so I did nothing with them.

>Remove everything in the wine module except the makefiles

This is best done from cvs proper.  I will leave them for now.


Rex Jolliff
re...@lv...