Re: Cygwin NT DDK Project

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

>In short: CygWin is a (_GREAT_) porting tool, with MinGW a very good
>target for "usual" applications. Using it for driver purposes looks to me,
>at this stage, a waste of time; full support for all the available user
>mode APIs would be a much more useful project.

I use the Cygwin's little child: mingw32. Ld can build native applications 
(*) and, since kernel mode drivers are native DLLs, it probably can build 
them too. Unfortunately, as Mumit confirmed prevately, gcc can not handle 
the __fastcall calling convention which is required to call some frequently 
used system calls from kernel mode, so it is not complete yet for a free WNT 
DDK.

(*) You simply need to replace main() with void 
NtProcessStartup(PPROCESS_STARTUP ps); but they are hard to write 
applications, since can link only to ntdll.dll and a few other core DLLs.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Chris Telting]

----- Original Message -----
From: Emanuele Aliberti <ealiberti@hotmail.com>
To: <bianchi@www.arte.unipi.it>; <telting@sprynet.com>
Cc: <cygwin@sourceware.cygnus.com>
Sent: Thursday, August 26, 1999 12:41 PM
Subject: Re: Cygwin NT DDK Project


> >In short: CygWin is a (_GREAT_) porting tool, with MinGW a very good
> >target for "usual" applications. Using it for driver purposes looks to
me,
> >at this stage, a waste of time; full support for all the available user
> >mode APIs would be a much more useful project.
>
> I use the Cygwin's little child: mingw32. Ld can build native applications
> (*) and, since kernel mode drivers are native DLLs, it probably can build
> them too. Unfortunately, as Mumit confirmed prevately, gcc can not handle
> the __fastcall calling convention which is required to call some
frequently
> used system calls from kernel mode, so it is not complete yet for a free
WNT
> DDK.

That's all that's needed?  It only requires a keyword and code to generate
the fastcalls which is minimal.  Even I can do that.  If that's what's
needed then
I volunteer to do it myself.  I also know as a fact that the linker needs to
be
changed.

There actually needs to be a flag set in the pe header in order for it to be
a
valid but again that's minimal.

Does anyone actually want this?  I figured that it would be minimal to
implement if it weren't already implemented.  I personally think that the
gnu tools would be a superior build environment than currently exists
with the NT DDK.

And I'd personally like to see a free nt fs kit; at a minimal all the
required
include headers and import libraries.  Possibly minimal documentation
of what people have so far figured out indipendently about making such
drivers.

<PONDERING>
On a seperate issue.  I was posdering the possibility of a virtual
 subsystem for nt drivers for linux.  Mostly the mini drivers such as
printers
and possibly video.  While it wouldn't be as good as native drivers; still
slow drivers are better than no drivers.  Anyone see any problems with
this?  It's certianly is alot of work but can anyone suggest as fundimental
or legal reasons why it wouldn't be possible?
</PONDERING>


BlueCoder
bluecoder@rocketmail.com
May you live as long as you wish and love as long as you live.




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Mumit Khan]

"Chris Telting" <telting@sprynet.com> writes:
> 
> 
> That's all that's needed?  It only requires a keyword and code to generate
> the fastcalls which is minimal.  Even I can do that.  If that's what's
> needed then
> I volunteer to do it myself.  I also know as a fact that the linker needs to
> be
> changed.

I had an implementation of fastcall a long time ago, but never added it
since nobody asked for it. I can dig it out and send it to you if you
want to play with it. It requires a change to the backend to handle
the special calling convention (from what I remember, it was a cross
between regparm and stdcall), but as far as I can tell, no change 
to linker necessary. Could you please explain why you think the linker 
needs to be changed to support it?

> There actually needs to be a flag set in the pe header in order for it to be
> a
> valid but again that's minimal.

Please elaborate why fastcall requires PE header flag change. I'm going
through the MSDN docs right now, but that always takes a while. Pointers
welcome.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Love]

"Chris Telting" <telting@sprynet.com> writes:

> That's all that's needed?

The try { } finally { } and try { } except () { } handling that is part of
the SEH. You need SEH if you want to talk to the CacheManager.

> Does anyone actually want this?  I figured that it would be minimal to
> implement if it weren't already implemented.  I personally think that the
> gnu tools would be a superior build environment than currently exists
> with the NT DDK.
 
It would be good, since people could hack on the code w/o getting ms
software.

> And I'd personally like to see a free nt fs kit; at a minimal all the
> required include headers and import libraries.  Possibly minimal
> documentation of what people have so far figured out indipendently about
> making such drivers.

You are in luck: < http://www.acc.umu.se/~bosse/ntifs.h >.

I have written the beging a xfs driver (i.e just loads and have a create)
((no, not SGI xfs, one of the other ones, namely the xfs that is part of
arla http://www.stacken.kth.se/projekt/arla/ >)) Guess there will be more
code hacked soon (If I just get the time).

Love




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Cygwin NT DDK Project and ntifs.h

[Federico Bianchi]

On 27 Aug 1999, Love wrote:

> "Chris Telting" <telting@sprynet.com> writes:
> 
> > That's all that's needed?
> 
> The try { } finally { } and try { } except () { } handling that is part of
> the SEH. You need SEH if you want to talk to the CacheManager.

Well, apart from the __fastcall convention, and SEH, you should at least
update the linker to handle the NATIVE subsystem and all the other driver
things (the MS CRC comes to mind). Symbols must be in *KD / WinDBG format
(at least until Micro$oft doesn't document fully how the remote kernel
debugging facility work) unless you are going to happily trace into pure
machine code. 

Both the DDK and the system itself make a lot of (sometimes hidden)
assumptions about how the compiler works, and this is going to worsen due
to the use of floating point / MMX-whatever and C++ code in kernel mode -
just think of how the name mangling operates on gcc and MSVC and you'll
why I think a Cygwin DDK is probably too ambitious a goal at this stage
(NASM or - ykes! - GAS/GASP might find their role much earlier, though -
but this is a different option).

SEH would actually be an interesting project in its own rights, since it
can be useful in user mode as well (just think of Windows CE and gcc +
MinGW library). So would be a gcc IFS or _user_level_ DDK one (for
printer drivers, virtual device drivers or the likes, say). I personally
hate the fact I need four DDK (95, 98, NT 4.0 and NT5.0/Win2k beta 3, plus
hundreds of other files not found in them) installed when I want to target
Micro$oft systems, with a hell lot of duplicate code.

> > And I'd personally like to see a free nt fs kit; at a minimal all the
> > required include headers and import libraries.  Possibly minimal
> > documentation of what people have so far figured out indipendently about
> > making such drivers.
> 
> You are in luck: < http://www.acc.umu.se/~bosse/ntifs.h >.

That's really nice! I was looking for some IFS code under NT (see the
ext2fs thread of discussion).
 
> I have written the beging a xfs driver (i.e just loads and have a create)
> ((no, not SGI xfs, one of the other ones, namely the xfs that is part of
> arla http://www.stacken.kth.se/projekt/arla/ >)) Guess there will be more
> code hacked soon (If I just get the time).

Nice to know, as well

Best regards to you all

	 		Federico Bianchi
			Dipartimento di Storia delle Arti
			Universita` degli Studi di Pisa
			p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy)
			tel. +39-050-587111 (cent.), +39-050-587224 (uff.)
			fax. +39-050-580128; e-mail: <f.bianchi@arte.unipi.it>
			===================================================
			!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
			===================================================


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Love]

"Chris Telting" <telting@sprynet.com> writes:

> That's all that's needed?

The try { } finally { } and try { } except () { } handling that is part of
the SEH. You need SEH if you want to talk to the CacheManager.

> Does anyone actually want this?  I figured that it would be minimal to
> implement if it weren't already implemented.  I personally think that the
> gnu tools would be a superior build environment than currently exists
> with the NT DDK.
 
It would be good, since people could hack on the code w/o getting ms
software.

> And I'd personally like to see a free nt fs kit; at a minimal all the
> required include headers and import libraries.  Possibly minimal
> documentation of what people have so far figured out indipendently about
> making such drivers.

You are in luck: < http://www.acc.umu.se/~bosse/ntifs.h >.

I have written the beging a xfs driver (i.e just loads and have a create)
((no, not SGI xfs, one of the other ones, namely the xfs that is part of
arla http://www.stacken.kth.se/projekt/arla/ >)) Guess there will be more
code hacked soon (If I just get the time).

Love




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

>In short: CygWin is a (_GREAT_) porting tool, with MinGW a very good
>target for "usual" applications. Using it for driver purposes looks to me,
>at this stage, a waste of time; full support for all the available user
>mode APIs would be a much more useful project.

I use the Cygwin's little child: mingw32. Ld can build native applications 
(*) and, since kernel mode drivers are native DLLs, it probably can build 
them too. Unfortunately, as Mumit confirmed prevately, gcc can not handle 
the __fastcall calling convention which is required to call some frequently 
used system calls from kernel mode, so it is not complete yet for a free WNT 
DDK.

(*) You simply need to replace main() with void 
NtProcessStartup(PPROCESS_STARTUP ps); but they are hard to write 
applications, since can link only to ntdll.dll and a few other core DLLs.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Cygwin NT DDK Project and ntifs.h

[Federico Bianchi]

On 27 Aug 1999, Love wrote:

> "Chris Telting" <telting@sprynet.com> writes:
> 
> > That's all that's needed?
> 
> The try { } finally { } and try { } except () { } handling that is part of
> the SEH. You need SEH if you want to talk to the CacheManager.

Well, apart from the __fastcall convention, and SEH, you should at least
update the linker to handle the NATIVE subsystem and all the other driver
things (the MS CRC comes to mind). Symbols must be in *KD / WinDBG format
(at least until Micro$oft doesn't document fully how the remote kernel
debugging facility work) unless you are going to happily trace into pure
machine code. 

Both the DDK and the system itself make a lot of (sometimes hidden)
assumptions about how the compiler works, and this is going to worsen due
to the use of floating point / MMX-whatever and C++ code in kernel mode -
just think of how the name mangling operates on gcc and MSVC and you'll
why I think a Cygwin DDK is probably too ambitious a goal at this stage
(NASM or - ykes! - GAS/GASP might find their role much earlier, though -
but this is a different option).

SEH would actually be an interesting project in its own rights, since it
can be useful in user mode as well (just think of Windows CE and gcc +
MinGW library). So would be a gcc IFS or _user_level_ DDK one (for
printer drivers, virtual device drivers or the likes, say). I personally
hate the fact I need four DDK (95, 98, NT 4.0 and NT5.0/Win2k beta 3, plus
hundreds of other files not found in them) installed when I want to target
Micro$oft systems, with a hell lot of duplicate code.

> > And I'd personally like to see a free nt fs kit; at a minimal all the
> > required include headers and import libraries.  Possibly minimal
> > documentation of what people have so far figured out indipendently about
> > making such drivers.
> 
> You are in luck: < http://www.acc.umu.se/~bosse/ntifs.h >.

That's really nice! I was looking for some IFS code under NT (see the
ext2fs thread of discussion).
 
> I have written the beging a xfs driver (i.e just loads and have a create)
> ((no, not SGI xfs, one of the other ones, namely the xfs that is part of
> arla http://www.stacken.kth.se/projekt/arla/ >)) Guess there will be more
> code hacked soon (If I just get the time).

Nice to know, as well

Best regards to you all

	 		Federico Bianchi
			Dipartimento di Storia delle Arti
			Universita` degli Studi di Pisa
			p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy)
			tel. +39-050-587111 (cent.), +39-050-587224 (uff.)
			fax. +39-050-580128; e-mail: <f.bianchi@arte.unipi.it>
			===================================================
			!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
			===================================================


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Mumit Khan]

"Chris Telting" <telting@sprynet.com> writes:
> 
> 
> That's all that's needed?  It only requires a keyword and code to generate
> the fastcalls which is minimal.  Even I can do that.  If that's what's
> needed then
> I volunteer to do it myself.  I also know as a fact that the linker needs to
> be
> changed.

I had an implementation of fastcall a long time ago, but never added it
since nobody asked for it. I can dig it out and send it to you if you
want to play with it. It requires a change to the backend to handle
the special calling convention (from what I remember, it was a cross
between regparm and stdcall), but as far as I can tell, no change 
to linker necessary. Could you please explain why you think the linker 
needs to be changed to support it?

> There actually needs to be a flag set in the pe header in order for it to be
> a
> valid but again that's minimal.

Please elaborate why fastcall requires PE header flag change. I'm going
through the MSDN docs right now, but that always takes a while. Pointers
welcome.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Chris Telting]

----- Original Message -----
From: Emanuele Aliberti <ealiberti@hotmail.com>
To: <bianchi@www.arte.unipi.it>; <telting@sprynet.com>
Cc: <cygwin@sourceware.cygnus.com>
Sent: Thursday, August 26, 1999 12:41 PM
Subject: Re: Cygwin NT DDK Project


> >In short: CygWin is a (_GREAT_) porting tool, with MinGW a very good
> >target for "usual" applications. Using it for driver purposes looks to
me,
> >at this stage, a waste of time; full support for all the available user
> >mode APIs would be a much more useful project.
>
> I use the Cygwin's little child: mingw32. Ld can build native applications
> (*) and, since kernel mode drivers are native DLLs, it probably can build
> them too. Unfortunately, as Mumit confirmed prevately, gcc can not handle
> the __fastcall calling convention which is required to call some
frequently
> used system calls from kernel mode, so it is not complete yet for a free
WNT
> DDK.

That's all that's needed?  It only requires a keyword and code to generate
the fastcalls which is minimal.  Even I can do that.  If that's what's
needed then
I volunteer to do it myself.  I also know as a fact that the linker needs to
be
changed.

There actually needs to be a flag set in the pe header in order for it to be
a
valid but again that's minimal.

Does anyone actually want this?  I figured that it would be minimal to
implement if it weren't already implemented.  I personally think that the
gnu tools would be a superior build environment than currently exists
with the NT DDK.

And I'd personally like to see a free nt fs kit; at a minimal all the
required
include headers and import libraries.  Possibly minimal documentation
of what people have so far figured out indipendently about making such
drivers.

<PONDERING>
On a seperate issue.  I was posdering the possibility of a virtual
 subsystem for nt drivers for linux.  Mostly the mini drivers such as
printers
and possibly video.  While it wouldn't be as good as native drivers; still
slow drivers are better than no drivers.  Anyone see any problems with
this?  It's certianly is alot of work but can anyone suggest as fundimental
or legal reasons why it wouldn't be possible?
</PONDERING>


BlueCoder
bluecoder@rocketmail.com
May you live as long as you wish and love as long as you live.




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Cygwin NT DDK Project

[Suhaib Siddiqi]

Sounds like you might be abig help for us for our XFree86 proting project. I
am at last hurdle of solving devices drivers issue.

Would care to help?  It would be highly appreciated.

Regards
Suhaib

> -----Original Message-----
> From: cygwin-owner@sourceware.cygnus.com
> [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of Chris Telting
> Sent: Monday, August 23, 1999 10:55 PM
> To: Cygwin Mailing List
> Subject: Cygwin NT DDK Project
>
>
> Win2000 drivers are basicly NT drivers so such a ddk would likely
> be useful
> for some time to come.
>
> If anyone is interested in starting an NT DDK for cygwin/ming so
> that it can
> compile nt drivers, I am more than willing to contribute.
>
>
> BlueCoder
> bluecoder@rocketmail.com
> May you live as long as you wish and love as long as you live.
>
>
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Cygwin NT DDK Project

[Chris Telting]

Win2000 drivers are basicly NT drivers so such a ddk would likely be useful
for some time to come.

If anyone is interested in starting an NT DDK for cygwin/ming so that it can
compile nt drivers, I am more than willing to contribute.


BlueCoder
bluecoder@rocketmail.com
May you live as long as you wish and love as long as you live.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Federico Bianchi]

Quite , to say the least.

a) NT 5.0 (Win2k) drivers are similar to NT 4.0 ones, but there are some
   key differences, notably in the PnP support; moreover, the video
   subsystem has changed and the IFS layer (which is not documented at
   all, as you already know) has been extended quite a bit. And I left 
   out the whole "streaming API" concept (which I am not sure I fully
   understand myself), with all of its implications on most drivers
   (video, network, audio, input).This is why, e.g., Micro$oft lets you
   download both DDKs.
b) Microsoft DDKs are closely linked to MSVC (by the way, the supported
   version is still 5.0), with all its quirks, its calling conventions and
   its extensions (see the full plethora of __declspec and #pragma
   options, for example). And it's not just good old C: the NT 5.0 IFS kit
   is supposed to use C++ features (notably virtual class members), and NT
   5.0 WDM may use floating point code. And I didn't mention the
   problems related to the absence of a C run-time library (much less a
   CygWin-like one). If you _REALLY_ want to sidestep Microsoft compilers
   for DDK usage, NASM might be a good candidate, even if optimizing
   assembler for the new CPUs is getting harder and harder.

In short: CygWin is a (_GREAT_) porting tool, with MinGW a very good
target for "usual" applications. Using it for driver purposes looks to me,
at this stage, a waste of time; full support for all the available user
mode APIs would be a much more useful project.

Best regards to you all

	 		Federico Bianchi
			Dipartimento di Storia delle Arti
			Universita` degli Studi di Pisa
			p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy)
			tel. +39-050-587111 (cent.), +39-050-587224 (uff.)
			fax. +39-050-580128; e-mail: <f.bianchi@arte.unipi.it>
			===================================================
			!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
			===================================================



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

>Please elaborate why fastcall requires PE header flag change. I'm going
>through the MSDN docs right now, but that always takes a while. Pointers
>welcome.

I am not sure, but probably Chris refers to the checksum field in the PE 
header, which is now 0, and must contain a valid value for any kernel module 
to be loaded.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

>If anyone is interested in starting an NT DDK for cygwin/ming so that it 
>can
>compile nt drivers, I am more than willing to contribute.

Please check http://reactos.com/ . Browse the code from the download section 
or from cvs server. There is some kernel mode code (drivers) that is not 
exactly for NT, but that requires (will require) a WNT DDK.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

[__fastcall]
>That's all that's needed?  It only requires a keyword and code to generate
>the fastcalls which is minimal.  Even I can do that.  If that's what's
>needed then
>I volunteer to do it myself.  I also know as a fact that the linker needs 
>to
>be
>changed.

Also name decoration is different:

cfoo(int,int,int);
__stdcall sfoo(int,int,int);
__fastcall ffoo(int,int,int);

became

_cfoo
_sfoo@12
@ffoo@4

and, at present, dlltool can not handle symbols beginning with a '@'.

>There actually needs to be a flag set in the pe header in order for it to 
>be
>a
>valid but again that's minimal.

You are right: I forgot that. WNT checks strictly kernel modules it loads.

>Does anyone actually want this?  I figured that it would be minimal to
>implement if it weren't already implemented.  I personally think that the
>gnu tools would be a superior build environment than currently exists
>with the NT DDK.
>
>And I'd personally like to see a free nt fs kit; at a minimal all the
>required
>include headers and import libraries.  Possibly minimal documentation
>of what people have so far figured out indipendently about making such
>drivers.

The reactos source base has headers for most kernel-exported symbols that we 
currently use with egcs 1.1.2 and gcc 2.95. We still need to merge with the 
ntifs.h though. We planned an SDK/DDK for the (far?) future, but now are 
concentrating on kernel development.

>On a seperate issue.  I was posdering the possibility of a virtual
>  subsystem for nt drivers for linux.  Mostly the mini drivers such as
>printers
>and possibly video.

Some of us proposed that, but it was decided to let it to volunteers, 
because the development of support for native nt drivers is quite expensive 
in terms of code and time.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

>Please elaborate why fastcall requires PE header flag change. I'm going
>through the MSDN docs right now, but that always takes a while. Pointers
>welcome.

I am not sure, but probably Chris refers to the checksum field in the PE 
header, which is now 0, and must contain a valid value for any kernel module 
to be loaded.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

[__fastcall]
>That's all that's needed?  It only requires a keyword and code to generate
>the fastcalls which is minimal.  Even I can do that.  If that's what's
>needed then
>I volunteer to do it myself.  I also know as a fact that the linker needs 
>to
>be
>changed.

Also name decoration is different:

cfoo(int,int,int);
__stdcall sfoo(int,int,int);
__fastcall ffoo(int,int,int);

became

_cfoo
_sfoo@12
@ffoo@4

and, at present, dlltool can not handle symbols beginning with a '@'.

>There actually needs to be a flag set in the pe header in order for it to 
>be
>a
>valid but again that's minimal.

You are right: I forgot that. WNT checks strictly kernel modules it loads.

>Does anyone actually want this?  I figured that it would be minimal to
>implement if it weren't already implemented.  I personally think that the
>gnu tools would be a superior build environment than currently exists
>with the NT DDK.
>
>And I'd personally like to see a free nt fs kit; at a minimal all the
>required
>include headers and import libraries.  Possibly minimal documentation
>of what people have so far figured out indipendently about making such
>drivers.

The reactos source base has headers for most kernel-exported symbols that we 
currently use with egcs 1.1.2 and gcc 2.95. We still need to merge with the 
ntifs.h though. We planned an SDK/DDK for the (far?) future, but now are 
concentrating on kernel development.

>On a seperate issue.  I was posdering the possibility of a virtual
>  subsystem for nt drivers for linux.  Mostly the mini drivers such as
>printers
>and possibly video.

Some of us proposed that, but it was decided to let it to volunteers, 
because the development of support for native nt drivers is quite expensive 
in terms of code and time.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Emanuele Aliberti]

>If anyone is interested in starting an NT DDK for cygwin/ming so that it 
>can
>compile nt drivers, I am more than willing to contribute.

Please check http://reactos.com/ . Browse the code from the download section 
or from cvs server. There is some kernel mode code (drivers) that is not 
exactly for NT, but that requires (will require) a WNT DDK.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Cygwin NT DDK Project

[Suhaib Siddiqi]

Sounds like you might be abig help for us for our XFree86 proting project. I
am at last hurdle of solving devices drivers issue.

Would care to help?  It would be highly appreciated.

Regards
Suhaib

> -----Original Message-----
> From: cygwin-owner@sourceware.cygnus.com
> [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of Chris Telting
> Sent: Monday, August 23, 1999 10:55 PM
> To: Cygwin Mailing List
> Subject: Cygwin NT DDK Project
>
>
> Win2000 drivers are basicly NT drivers so such a ddk would likely
> be useful
> for some time to come.
>
> If anyone is interested in starting an NT DDK for cygwin/ming so
> that it can
> compile nt drivers, I am more than willing to contribute.
>
>
> BlueCoder
> bluecoder@rocketmail.com
> May you live as long as you wish and love as long as you live.
>
>
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin NT DDK Project

[Federico Bianchi]

Quite , to say the least.

a) NT 5.0 (Win2k) drivers are similar to NT 4.0 ones, but there are some
   key differences, notably in the PnP support; moreover, the video
   subsystem has changed and the IFS layer (which is not documented at
   all, as you already know) has been extended quite a bit. And I left 
   out the whole "streaming API" concept (which I am not sure I fully
   understand myself), with all of its implications on most drivers
   (video, network, audio, input).This is why, e.g., Micro$oft lets you
   download both DDKs.
b) Microsoft DDKs are closely linked to MSVC (by the way, the supported
   version is still 5.0), with all its quirks, its calling conventions and
   its extensions (see the full plethora of __declspec and #pragma
   options, for example). And it's not just good old C: the NT 5.0 IFS kit
   is supposed to use C++ features (notably virtual class members), and NT
   5.0 WDM may use floating point code. And I didn't mention the
   problems related to the absence of a C run-time library (much less a
   CygWin-like one). If you _REALLY_ want to sidestep Microsoft compilers
   for DDK usage, NASM might be a good candidate, even if optimizing
   assembler for the new CPUs is getting harder and harder.

In short: CygWin is a (_GREAT_) porting tool, with MinGW a very good
target for "usual" applications. Using it for driver purposes looks to me,
at this stage, a waste of time; full support for all the available user
mode APIs would be a much more useful project.

Best regards to you all

	 		Federico Bianchi
			Dipartimento di Storia delle Arti
			Universita` degli Studi di Pisa
			p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy)
			tel. +39-050-587111 (cent.), +39-050-587224 (uff.)
			fax. +39-050-580128; e-mail: <f.bianchi@arte.unipi.it>
			===================================================
			!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
			===================================================



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Cygwin NT DDK Project

[Chris Telting]

Win2000 drivers are basicly NT drivers so such a ddk would likely be useful
for some time to come.

If anyone is interested in starting an NT DDK for cygwin/ming so that it can
compile nt drivers, I am more than willing to contribute.


BlueCoder
bluecoder@rocketmail.com
May you live as long as you wish and love as long as you live.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com