reactos-kernel

[ros-kernel] geoShell now runs under wine

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

it seems that WINE's commdlg32, comctl32 and shell32 are to the point that it can handle running
geoShell R4. This is good news because once ReactOS has Windowing we should be able to run it
using our port of the WINE dlls. I have been kinda busy the past week but will be resuming my work
on porting R4 to mingw over the next few days. 

Eye candy attached.
Thanks
Steven 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[ros-kernel] Mok downtime imminent

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

Hi all,

Sometime in the next week or two, mok will be down for a short
period of time, hopefully not longer than a couple days.  I am
moving and will be to have the cable connection transferred to
the new location.


Rex Jolliff
re...@lv...

Re: [ros-kernel] ReactOS 0.0.20

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

A new release inevitably brings more curious people to our site
though. The forums are down... I don't know how good that is. Our
contact at the new site is on vacation at the moment. We're working
to find another contact.

- Jason

--- Eric Kohl <ek...@rz...> wrote:
> Hi!
> 
> I guess we should release ReactOS 0.0.20 because:
> 
>     - 0.0.19 is more than 150 days old.
> 
>     - a lot of changes happened since 0.0.19.
> 
>     - we don't see any current showstoppers.
> 
> 
> Regards,
> Eric Kohl
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [ros-kernel] gcc version 2.95.3-6 (mingw special) V's gcc version 3.1 compatibility

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

l=F8r, 2002-07-27 kl. 20:00 skrev Robert Dickenson:
> Is there an internal defined symbol I can test in the source to make
> code build compatible between the two versions?
>=20
> Thanks, RobD.

Do you mean how to test for the different mingw runtimes?

If so, you can check the defined constants in _mingw.h.

Casper

[ros-kernel] gcc version 2.95.3-6 (mingw special) V's gcc version 3.1 compatibility

[Robert D. <od...@pn...>]

Is there an internal defined symbol I can test in the source to make
code build compatible between the two versions?

Thanks, RobD.

Re: [ros-kernel] ReactOS 0.0.20

[Royce M. I. <ro...@ev...>]

I'm sorry I haven't had time to see if you fixed the bug I've been having...

Between having a baby, and having to put my family in hiding because of a
family emergency, my life has been a living hell.

When my life finally gets back to normal I'll check and see if it's fixed.

Royce3

----- Original Message -----
From: "Eric Kohl" <ek...@rz...>
To: "ReactOS Kernel" <rea...@li...>
Sent: Saturday, July 27, 2002 10:25 AM
Subject: [ros-kernel] ReactOS 0.0.20


> Hi!
>
> I guess we should release ReactOS 0.0.20 because:
>
>     - 0.0.19 is more than 150 days old.
>
>     - a lot of changes happened since 0.0.19.
>
>     - we don't see any current showstoppers.
>
>
> Regards,
> Eric Kohl
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>

[ros-kernel] ReactOS 0.0.20

[Eric K. <ek...@rz...>]

Hi!

I guess we should release ReactOS 0.0.20 because:

    - 0.0.19 is more than 150 days old.

    - a lot of changes happened since 0.0.19.

    - we don't see any current showstoppers.


Regards,
Eric Kohl

Re: [ros-kernel] Unicode

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

The code fragment eric gave me works for the compiler.
However, (atleast for me) there is the question wether it does actually 
the right. But why should it.

BTW your program returns 2. But I used wchar_t instead, cos there was no 
__wchar_t

Magefire k'Vala schrieb:

> At 02:14 AM 7/26/2002 +0200, Robert K. wrote:
>
>> Where is my Fault?
>>
>>    NT::UNICODE_STRING unistr;
>>    NT::NTSTATUS stat;
>>    NT::OBJECT_ATTRIBUTES oa = {sizeof oa, 0, &unistr, 
>> NT::OBJ_CASE_INSENSITIVE, 0, 0};
>>
>>    // init String still bevore use.
>>    NT::RtlInitUnicodeString( &unistr, L"\\\\.\\Beep" );
>>           ---------------------------^
>> This results in
>> misc/error.cpp:36: passing `const __wchar_t *' as argument 2 of 
>> `NT::RtlInitUnicodeString(NT::_UNICODE_STRING *, const short unsigned 
>> int *)'
>
>
> Check your gcc configuration - Unix (and thus, on average gcc) 
> traditionally use a 4-byte wchar_t; Win32
> uses a 2-byte one. Try building and running the following program, and 
> see what it says.
>
> #include <stdio.h>
> #include <wchar.h>
>
> int main(int argc, char **argv)
> {
>     printf("sizeof(__wchar_t) = %d\n", sizeof(__wchar_t));
> }
>
> -- BKS
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] Unicode

[Kohn E. D. <em...@cs...>]

While in C, wchar_t is just a typedef for something that is able to hold a
wide character (such as unsigned short), in C++ wchar_t is a distinct
type, built into the language.

In my opinion, the definition of PWSTR is broken (it should have been a
typedef to wchar_t*)



								Emil

On Fri, 26 Jul 2002, Eric Kohl wrote:

>
> "Robert K." <ro...@ko...> wrote:
>
>
> > Where is my Fault?
> >
> >   NT::UNICODE_STRING unistr;
> >   NT::NTSTATUS stat;
> >   NT::OBJECT_ATTRIBUTES oa = {sizeof oa, 0, &unistr,
> > NT::OBJ_CASE_INSENSITIVE, 0, 0};
> >
> >   // init String still bevore use.
> >   NT::RtlInitUnicodeString( &unistr, L"\\\\.\\Beep" );
> >          ---------------------------^
> > This results in
> > misc/error.cpp:36: passing `const __wchar_t *' as argument 2 of
> > `NT::RtlInitUnicodeString(NT::_UNICODE_STRING *, const short unsigned
> > int *)'
>
> IFAICS, 'const __wchar_t *' and 'const short unsigned int*' are different
> types. You might have to use
> (PWSTR)L"\\\\.\\Beep" instead.
>
>
> > Is the kernel32.dll written in that way that one can run both Unicode
> > appsand ANSI ones?
> > cos it doesn't look like.
>
> Yes, kernel32.dll supports UNICODE and ANSI apps. For example, have a look
> at the function CreateProcess(). A UNICODE application will call
> CreateProcessW() and an ANSI application will call CreateProcessA().
> Kernel32.dll implements both functions.
>
> Eric
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>

Re: [ros-kernel] Unicode

[Magefire k'V. <ti...@ya...>]

At 02:14 AM 7/26/2002 +0200, Robert K. wrote:
>Where is my Fault?
>
>    NT::UNICODE_STRING unistr;
>    NT::NTSTATUS stat;
>    NT::OBJECT_ATTRIBUTES oa = {sizeof oa, 0, &unistr, 
> NT::OBJ_CASE_INSENSITIVE, 0, 0};
>
>    // init String still bevore use.
>    NT::RtlInitUnicodeString( &unistr, L"\\\\.\\Beep" );
>           ---------------------------^
>This results in
>misc/error.cpp:36: passing `const __wchar_t *' as argument 2 of 
>`NT::RtlInitUnicodeString(NT::_UNICODE_STRING *, const short unsigned int *)'

Check your gcc configuration - Unix (and thus, on average gcc) 
traditionally use a 4-byte wchar_t; Win32
uses a 2-byte one. Try building and running the following program, and see 
what it says.

#include <stdio.h>
#include <wchar.h>

int main(int argc, char **argv)
{
     printf("sizeof(__wchar_t) = %d\n", sizeof(__wchar_t));
}

-- BKS

Re: [ros-kernel] Unicode

[Eric K. <ek...@rz...>]

"Robert K." <ro...@ko...> wrote:


> Where is my Fault?
>
>     NT::UNICODE_STRING unistr;
>     NT::NTSTATUS stat;
>     NT::OBJECT_ATTRIBUTES oa = {sizeof oa, 0, &unistr,
> NT::OBJ_CASE_INSENSITIVE, 0, 0};
>
>     // init String still bevore use.
>     NT::RtlInitUnicodeString( &unistr, L"\\\\.\\Beep" );
>            ---------------------------^
> This results in
> misc/error.cpp:36: passing `const __wchar_t *' as argument 2 of
> `NT::RtlInitUnicodeString(NT::_UNICODE_STRING *, const short unsigned
> int *)'

IFAICS, 'const __wchar_t *' and 'const short unsigned int*' are different
types. You might have to use
(PWSTR)L"\\\\.\\Beep" instead.


> Is the kernel32.dll written in that way that one can run both Unicode
> apps and ANSI ones?
> cos it doesn't look like.

Yes, kernel32.dll supports UNICODE and ANSI apps. For example, have a look
at the function CreateProcess(). A UNICODE application will call
CreateProcessW() and an ANSI application will call CreateProcessA().
Kernel32.dll implements both functions.

Eric

Re: [ros-kernel] dflat and drivers

[Eric K. <ek...@rz...>]

"Robert K." <ro...@ko...> wrote:

Hello Robert!

> Hi,
> I plan to make a driver start and stop applet.
> So, does souch a thing already exist?

Services.exe should start and stop drivers. But at present it is still far
from being able to handle this task. Any 'driver start and stop applet' (aka
'Service Control Program' or 'SCP') should instruct services.exe (aka
'Service Control Manager' or 'SCM') to start or stop a driver. So the short
answer to your question is: No!

> I plan to use plain c with WindowProc etc. pp = simple and efficient.
> What is dflat for. Is it possible to write dualmode applications with
> that lib, or
> is it at least possible to have either a textmode app or an win app?
> Are the apis mostly compatible?

Dflat32 was planned to become a universal textmode user interface library to
support the development of powerful console mode applications. But because
there was a much stronger demand for low-level improvements my focus moved
to the kernel-mode side of the project.

Dual-mode applications are *not* supported because console-mode and gui-mode
differ in too many ways. The APIs were designed to be almost compatible with
the win32 APIs. One major problem is the good chance of stumbling upon
name-collisions caused by Dflat32. All Dflat32-APIs should use a 'Df'-prefix
to prevent these collisions.

> And what is the Systemcall to load a driver?
The function to load a driver is NtLoadDriver(). To unload a driver call
NtUnloadDriver(). NtUnloadDriver() is not implemented yet!

Eric

RE: [ros-kernel] Seperate project for drivers?

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

At 01:57 AM 7/25/02 -0700, you wrote:
>Ok so would this project accept drivers written in Pascal? Inside
>ReactOS this is frowned upon - but this new site could possibly
>accept it.

My only concern would be that we want as few tools as possible to
build our core system, and there are some drivers that must be
considered part of the core system.  Other than the core drivers,
I would hope that we can get close enough to the NT spec that
we can leverage most of the available 3rd party drivers.  So I don't
see a problem with supporting another site for optional drivers, if
we keep the core drivers with the OS.


Rex Jolliff
re...@lv...

[ros-kernel] Unicode

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

Where is my Fault?

    NT::UNICODE_STRING unistr;
    NT::NTSTATUS stat;
    NT::OBJECT_ATTRIBUTES oa = {sizeof oa, 0, &unistr, 
NT::OBJ_CASE_INSENSITIVE, 0, 0};

    // init String still bevore use.
    NT::RtlInitUnicodeString( &unistr, L"\\\\.\\Beep" );
           ---------------------------^
This results in
misc/error.cpp:36: passing `const __wchar_t *' as argument 2 of 
`NT::RtlInitUnicodeString(NT::_UNICODE_STRING *, const short unsigned 
int *)'

AND

I decided to put os2 in the namespace OS2 and ntdll into NT. Of course 
only inside the os2ss
May there arise conflicts. Comments, Suggestions?
One problem are the defines that conflict.



Is the kernel32.dll written in that way that one can run both Unicode 
apps and ANSI ones?
cos it doesn't look like.

thx

[ros-kernel] cvs organization

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

Hi
how current is the .../dk directory.
Is it still intendet to place subsystem headers there.

I for my part would like to leave them in the os2/include  dir

[ros-kernel] dflat and drivers

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

Hi,
I plan to make a driver start and stop applet.
So, does souch a thing already exist?

I plan to use plain c with WindowProc etc. pp = simple and efficient.
What is dflat for. Is it possible to write dualmode applications with 
that lib, or
is it at least possible to have either a textmode app or an win app?
Are the apis mostly compatible?

And what is the Systemcall to load a driver?

RE: [ros-kernel] Seperate project for drivers?

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

We're going to have to try to support drivers that contain who the hell knows what anyway with the
binary compat goal so I dont see why it would matter as long as they follow WDM. WDM is source
portable accross CPUs according to M$.

Steven

--- Jason Filby <jas...@ya...> wrote:
> Ok so would this project accept drivers written in Pascal? Inside
> ReactOS this is frowned upon - but this new site could possibly
> accept it.
> 
> Any input from others?
> 
> Thanks
> - Jason


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [ros-kernel] Seperate project for drivers?

[James M. <jid...@sa...>]

Does someone have a link to this project(Open Source Windows Drivers)?
--=20
James Marjie

RE: [ros-kernel] Seperate project for drivers?

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

Ok so would this project accept drivers written in Pascal? Inside
ReactOS this is frowned upon - but this new site could possibly
accept it.

Any input from others?

Thanks
- Jason

--- Michael Rich <alp...@al...> wrote:
> > What looks promising is this: a seperate project for Open Source
> > Windows drivers. Both projects would benefit from this
> cooperation, I
> > would think, and this could be another way to attract more
> developers
> > to ReactOS.
> 
> Personally I think it would be a good idea.  I run NT4 on an Alpha,
> so
> my number one problem is lack of drivers.  A project that developed
> drivers would be really big help and most likely draw a lot of misc
> driver writers into help on little bits and pieces.
> 
> As far as NT4 goes, off the top of my head, the following would be
> nice:
> 
> USB driver support
> Firewire driver support
> 
> As far as NT4/Alpha goes...
> 
> TWAIN support
> NVIDIA driver support
> 
> Laters,
> michael
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

RE: [ros-kernel] Seperate project for drivers?

[Michael R. <alp...@al...>]

> What looks promising is this: a seperate project for Open Source
> Windows drivers. Both projects would benefit from this cooperation, I
> would think, and this could be another way to attract more developers
> to ReactOS.

Personally I think it would be a good idea.  I run NT4 on an Alpha, so
my number one problem is lack of drivers.  A project that developed
drivers would be really big help and most likely draw a lot of misc
driver writers into help on little bits and pieces.

As far as NT4 goes, off the top of my head, the following would be nice:

USB driver support
Firewire driver support

As far as NT4/Alpha goes...

TWAIN support
NVIDIA driver support

Laters,
michael

Re: [ros-kernel] Seperate project for drivers?

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

I forgot to mention: all of PetrOS is coded in Pascal..

--- Jason Filby <jas...@ya...> wrote:
> Hey all
> 
> I was mailing Peter Tattam of Trumpet Software a short while back.
> He's involved in the creation of PetrOS
> (http://www.petros-project.com/) - similar to ReactOS but closed
> source. We're trying to find ways to share resources and drivers
> appear to be a part of PetrOS that Peter is willing to make Open
> Source.
> 
> What looks promising is this: a seperate project for Open Source
> Windows drivers. Both projects would benefit from this cooperation,
> I
> would think, and this could be another way to attract more
> developers
> to ReactOS.
> 
> Comments n suggestions?
> 
> Thanks
> - Jason
> 
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[ros-kernel] Seperate project for drivers?

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

Hey all

I was mailing Peter Tattam of Trumpet Software a short while back.
He's involved in the creation of PetrOS
(http://www.petros-project.com/) - similar to ReactOS but closed
source. We're trying to find ways to share resources and drivers
appear to be a part of PetrOS that Peter is willing to make Open
Source.

What looks promising is this: a seperate project for Open Source
Windows drivers. Both projects would benefit from this cooperation, I
would think, and this could be another way to attract more developers
to ReactOS.

Comments n suggestions?

Thanks
- Jason






__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [ros-kernel] Where could I find a TO-DO list?

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

There is as yet not formal list. However, one should be able to
obtain such a list from the soon-to-be-installed bug tracking
software on reactos.org.

- Jason

--- Julius <ly...@sp...> wrote:
> Hello,
>   I'm new here and I want to ask where could I find reactos to-do
> list?
> 
> Julius
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[ros-kernel] Where could I find a TO-DO list?

[Julius <ly...@sp...>]

Hello,
  I'm new here and I want to ask where could I find reactos to-do list?

Julius

Re: [ros-kernel] Spam

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

Hang in there! ReactOS.com has already moved to the donated space on
Liquid Pages. We'll be moving back to our old mailing list system
soon and all the spam will then be stopped.

- Jason

--- Thomas Weidenmueller <in...@w3...> wrote:
> Hi,
> 
> Can anyone stop this spammers? Why can't we block them?
> 
> bye
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com