reactos-kernel

[ros-kernel] Undocumented pool type?

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

ExAllocatePoolWithTag()

what is a pool type value 0x10 ?

It seems it is not documented at all.


====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Sharing code with wine + 16 bit support

[Phillip S. <ps...@cf...>]

No, consoles are fully 32bit, and are already implemented in reactos.

At 10:45 PM 10/24/2001 +0200, you wrote:
>Anyway, 16-bit in NT is emulated AFAIK with the WOW (Windows On Windows).
>That can be done separately, no? And what about win32 console apps? Since
>they depends on the console, could they be affected by the absence of this
>support?

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Re: Sharing code with wine + 16 bit support

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

WOW and WOWEXEC call the 16 bit subsystem (ntvdm) and provide for
communication with other win16 and win32 apps via OLE and RPC.

-----Original Message-----
From: Derrick Jobidon
To: ros...@re...
Sent: 10/24/01 4:45 PM
Subject: [ros-kernel] Re:  Sharing code with wine + 16 bit support

> Does wine support 16bit apps?  We don't, and I don't see any need to
> either.  It has been many many years since we left the 16bit world
> behind.  We finally even got rid of the ISA bus.  I think we can drop
> 16bit
> windows/dos as well.

Anyway, 16-bit in NT is emulated AFAIK with the WOW (Windows On
Windows).
That can be done separately, no? And what about win32 console apps?
Since
they depends on the console, could they be affected by the absence of
this
support?

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/

[ros-kernel] Re: Sharing code with wine + 16 bit support

[Derrick J. <sep...@de...>]

> Does wine support 16bit apps?  We don't, and I don't see any need to
> either.  It has been many many years since we left the 16bit world
> behind.  We finally even got rid of the ISA bus.  I think we can drop
> 16bit
> windows/dos as well.

Anyway, 16-bit in NT is emulated AFAIK with the WOW (Windows On Windows).
That can be done separately, no? And what about win32 console apps? Since
they depends on the console, could they be affected by the absence of this
support?

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Re: Sharing code with wine

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

> >Wine modules that I do think is worth porting/sharing:
> >
> >gdi32.dll - obviously
> 
> Negative.  Wine's gdi32.dll implementation is completely 
> different from 
> ours.  Theirs does funky things to implement drawing on an X 
> display, ours 
> basically calls down to kernel mode where it is implemented 
> in win32k.sys 
> using DDI display drivers.

Ooops, my mistake. That should be "modules not worth porting/sharing" of
course ;o)

- Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Sharing code with wine

[James T. <jim...@ad...>]

Hi,
Casper Hornstrup wrote:
> 
> Porting wine code seem to be the hot topic these days, so I think it is
> time to discuss ways to share code with the wine project before having
> ported most wine code and no (easy) way to update it in the future.
> 

Yeah, sorry that is my fault too.

> FSF would have to grant the wine team permission to use the code.
> 
> Wine modules that I do think is worth porting/sharing:
> 
> gdi32.dll - obviously
> icmp.dll - OS dependent
> kernel32.dll - OS dependent
> ntdll.dll - obviously

> opengl32.dll - wine specific

Off the shelf software? DL from vender and install ~

> user32.dll - we will have calls directly to win32k.sys
> wnaspi32.dll - OS dependent
> all winsock related modules
> 

These should be (with some exceptions) core ROS dll's where the others
make reference to and should stay separate from the wine stuff.

When building comctl32.a and dll you need ntdll.a, kernel32.a, gdi32.a,
user32.a, crtdll.a and msvcrt.a. The next one is comdlg32.a it uses the
same plus comclt32.a and a few others. So we need to sort through the
wine source and determine a build priority tree where one dll depends
on another, etc.. Start reading the makefiles. 8^o More coffee anyone?

> and the 16-bit only DLL's.
> 

I do not think NT is downward compatible is it? The 2k book I have does
say something about it being a options or ?. 

> Let's discuss this topic and propose a plan for code integration to the
> wine developers.
> 
> - Casper
> 
Yes,
James

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Sharing code with wine + 16 bit support

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

Yes wine does. But TWIN is closer to the way NT does it.

Take a look at Willows TWIN, It runs on POSIX and MAC-OS 9.x systems and
unlike wine it can emulate a x86 CPU for dos/win16 apps. It runs on x86,
Sparc, PPC, and Alpha. I know this wouldnt be a true ntvdm but at least if
someone wanted to run a 16bit app it might be possible.


>and the 16-bit only DLL's.

Does wine support 16bit apps?  We don't, and I don't see any need to 
either.  It has been many many years since we left the 16bit world 
behind.  We finally even got rid of the ISA bus.  I think we can drop
16bit 
windows/dos as well.



###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/

[ros-kernel] Re: Sharing code with wine

[James T. <jim...@ad...>]

Jason Filby wrote:
> 
> Yes, we should definitely look at this. I just want to know what kind
> of headers WINE use? Would they also be able to use mingw headers?
> 
> Thanks
> - Jason
> 
Hi,
The windows headers are almost the same. For instance winuser.h in wine
has more information than the Ming windows headers. I ran into problems
porting with Ming and went back to Wine.

Wine header winuser.h has this

/* defines below are for all win versions (_WIN32_WINNT >= 0x0400) ||
 *                                        (_WIN32_WINDOWS > 0x0400) */
#define SPI_GETMOUSEHOVERWIDTH    98
#define SPI_SETMOUSEHOVERWIDTH    99
#define SPI_GETMOUSEHOVERHEIGHT   100
#define SPI_SETMOUSEHOVERHEIGHT   101
#define SPI_GETMOUSEHOVERTIME     102
#define SPI_SETMOUSEHOVERTIME     103
#define SPI_GETWHEELSCROLLLINES   104
#define SPI_SETWHEELSCROLLLINES   105
#define SPI_GETMENUSHOWDELAY      106
#define SPI_SETMENUSHOWDELAY      107
 
#define SPI_GETSHOWIMEUI          110
#define SPI_SETSHOWIMEUI          111
 
/* defines below are for all win versions WINVER >= 0x0500 */
#define SPI_GETMOUSESPEED         112
#define SPI_SETMOUSESPEED         113
#define SPI_GETSCREENSAVERRUNNING 114
#define SPI_GETDESKWALLPAPER      115  

and Ming doesn't as I can see.

Here is a good example why we should take Caspers advice for having
wine header and wine dll code separate. See the following statements
make reference to NT ONLY.

SPI_GETMOUSEHOVERHEIGHT 
     Windows NT only: Gets the height, in pixels, of the rectangle
     within which the mouse pointer has to stay for TrackMouseEvent
     to generate a WM_MOUSEHOVER message. The height is returned in
     a UINT pointed to by the pvParam parameter. 

SPI_GETMOUSEHOVERTIME 
     Windows NT only: Gets the time, in milliseconds, that the mouse
     pointer has to stay in the hover rectangle for TrackMouseEvent
     to generate a WM_MOUSEHOVER message. The time is returned in a
     UINT pointed to by the pvParam parameter. 

SPI_GETMOUSEHOVERWIDTH 
     Windows NT only: Gets the width, in pixels, of the rectangle
     within which the mouse pointer has to stay for TrackMouseEvent
     to generate a WM_MOUSEHOVER message. The width is returned in
     a UINT pointed to by the pvParam parameter.

I need these three for porting comctl32.c to ROS.

FYI,
James

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Sharing code with wine

[Phillip S. <ps...@cf...>]

At 07:21 PM 10/24/2001 +0200, you wrote:
>It has been mentioned on the ros-kernel list to use mingw headers
>instead
>of having separate headers due to the fact that 1) mingw headers have a
>greater chance of beeing updated more often 2) The mingw team could
>benefit
>from these headers (the ntddk case). Another possibillity is to have our
>own
>version of the Windows headers shared with wine.

I agree with merging our headers with mingw.

>I'm leaning towards the former - using mingw headers. This way may mean
>more
>work when updating shared wine code, because if there is a change in
>public
>Windows headers, both set of headers needs to be updated (wine and
>mingw).
>Of course, we could just do it properly from the start and implement the
>full
>set of Windows headers. Then this will not be a problem ;o)
>
>Wine modules that I do think is worth porting/sharing:
>
>gdi32.dll - obviously

Negative.  Wine's gdi32.dll implementation is completely different from 
ours.  Theirs does funky things to implement drawing on an X display, ours 
basically calls down to kernel mode where it is implemented in win32k.sys 
using DDI display drivers.

>icmp.dll - OS dependent
>kernel32.dll - OS dependent

Also reactos specific, or is that what you mean by OS specific?

>ntdll.dll - obviously

Again, no.  I don't even think that WINE has an ntdll, and ours is just a 
stub to call into the kernel.

>opengl32.dll - wine specific
>user32.dll - we will have calls directly to win32k.sys

Right, same as gdi32.

>wnaspi32.dll - OS dependent

I don't think we need to implement this one at all, it comes with most 
burner software ( which is the only thing that I know of that uses the darn 
POS ), and from my experience, they only work with the version that they 
come with.

>all winsock related modules

Also not going to be shared.  Our winsock dlls are going to make calls down 
to afd.sys in the kernel, wine's will make bsd sockets calls to the linux 
kernel.


>and the 16-bit only DLL's.

Does wine support 16bit apps?  We don't, and I don't see any need to 
either.  It has been many many years since we left the 16bit world 
behind.  We finally even got rid of the ISA bus.  I think we can drop 16bit 
windows/dos as well.


>Let's discuss this topic and propose a plan for code integration to the
>wine developers.
>
>- Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] AW: Re: AW: Re: AW: Re: Cache and memory manager

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

> -----Ursprungliche Nachricht-----
> Von:	David Welch [SMTP:we...@cw...]
> Gesendet am:	Dienstag, 23. Oktober 2001 23:56
> An:	ros...@re...
> Betreff:	[ros-kernel] Re: AW: Re: AW: Re: Cache and memory manager
> 
> Okay, for reference what are the bugs exactly?

MiAllocPageFromPagingFile() returns for each reserved page 
the entry 1 and the calculation of the used and free pages is wrong.
See also the comments in the diff output (marked with '-->'). 

- Hartmut

Index: pagefile.c
===================================================================
RCS file: /CVS/ReactOS/reactos/ntoskrnl/mm/pagefile.c,v
retrieving revision 1.12
diff -u -r1.12 pagefile.c
--- pagefile.c	2001/10/10 21:57:00	1.12
+++ pagefile.c	2001/10/24 17:21:56
@@ -97,7 +97,7 @@
  */
 #define FILE_FROM_ENTRY(i) ((i) >> 24)
 #define OFFSET_FROM_ENTRY(i) (((i) & 0xffffff) - 1)
-#define ENTRY_FROM_FILE_OFFSET(i, j) (((i) << 24) || ((j) + 1))
+#define ENTRY_FROM_FILE_OFFSET(i, j) (((i) << 24) | ((j) + 1))
 
 /* FUNCTIONS *****************************************************************/
 
@@ -123,7 +123,7 @@
 			Mdl,
 			&file_offset,
 			&Iosb,
-			FALSE);
+			TRUE);
    return(Status);
 }
 
@@ -204,24 +204,23 @@
 MiAllocPageFromPagingFile(PPAGINGFILE PagingFile)
 {
    KIRQL oldIrql;
-   ULONG i;
    ULONG off;
    
    KeAcquireSpinLock(&PagingFile->AllocMapLock, &oldIrql);
    
-   for (i = 0; i < PagingFile->AllocMapSize; i++)
-     {
-	off = find_first_zero_bit(PagingFile->AllocMap, 
-				  PagingFile->AllocMapSize * 32);
-	clear_bit(off % 32, &PagingFile->AllocMap[off / 32]);		--> The bit must be set.
-	PagingFile->UsedPages--;					--> Must be increment.
-	PagingFile->FreePages++;					--> Must be decrement.
+   off = find_first_zero_bit(PagingFile->AllocMap, 
+			     PagingFile->AllocMapSize * 32);
+   if (off < PagingFile->CurrentSize)					--> Check for a valid offset.
+   {
+	set_bit(off % 32, &PagingFile->AllocMap[off / 32]);
+	PagingFile->UsedPages++;
+	PagingFile->FreePages--;
 	KeReleaseSpinLock(&PagingFile->AllocMapLock, oldIrql);
 	return(off);
-     }
+   }
    
    KeReleaseSpinLock(&PagingFile->AllocMapLock, oldIrql);
-   return(0);
+   return(0xffffffff);							--> Return a nonvalid entry.
 }
 
 VOID 
@@ -237,7 +236,7 @@
    KeAcquireSpinLock(&PagingFileListLock, &oldIrql);
    KeAcquireSpinLockAtDpcLevel(&PagingFileList[i]->AllocMapLock);
    
-   set_bit(off % 32, &PagingFileList[i]->AllocMap[off / 32]);		--> Bit must be reset.
+   clear_bit(off % 32, &PagingFileList[i]->AllocMap[off / 32]);
    
    PagingFileList[i]->FreePages++;
    PagingFileList[i]->UsedPages--;
@@ -271,11 +270,10 @@
 	    PagingFileList[i]->FreePages >= 1)
 	  {	     
 	     off = MiAllocPageFromPagingFile(PagingFileList[i]);
-	     if (off != 0)
+	     if (off == 0xffffffff)						--> Check vor invalid value.
 	       {
+		  DPRINT1("MiAllocPageFromPagingFile() doesn't return a free page, but FreeCount is %d\n", PagingFileList[i]->FreePages);
 		  KeBugCheck(0);
-		  KeReleaseSpinLock(&PagingFileListLock, oldIrql);	--> Has no effect after KeBugCheck().
-		  return(STATUS_UNSUCCESSFUL);
 	       }
 	     MiUsedSwapPages++;
 	     MiFreeSwapPages--;

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Sharing code with wine

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

Yes, we should definitely look at this. I just want to know what kind
of headers WINE use? Would they also be able to use mingw headers?

Thanks
- Jason

--- Casper Hornstrup <ch...@us...> wrote:
> Porting wine code seem to be the hot topic these days, so I think
> it is
> time to discuss ways to share code with the wine project before
> having
> ported most wine code and no (easy) way to update it in the future.
> 
> >From looking through current wine code, I see that most wine DLL's
> can
> be shared between the two projects. There are occational references
> to
> wine/*.h in the wine DLL modules and some of the headers in that
> directory
> are wine specific, but most of then are not. IMHO, it will be in
> the
> best
> interest of both projects to share Windows API DLLs wherever
> possible.
> The reason for this is obvious; A DLL has to be implemented only
> once.
> 
> So what are the problems associated with such a project?
> 
> Structure - Should we move all the shared wine code into a separate
> directory like reactos/wine?
> 
> It has been mentioned on the ros-kernel list to use mingw headers
> instead
> of having separate headers due to the fact that 1) mingw headers
> have a
> greater chance of beeing updated more often 2) The mingw team could
> benefit
> from these headers (the ntddk case). Another possibillity is to
> have our
> own
> version of the Windows headers shared with wine.
> 
> I'm leaning towards the former - using mingw headers. This way may
> mean
> more
> work when updating shared wine code, because if there is a change
> in
> public
> Windows headers, both set of headers needs to be updated (wine and
> mingw).
> Of course, we could just do it properly from the start and
> implement the
> full
> set of Windows headers. Then this will not be a problem ;o)
> 
> Synchronization - How do we synchronize between the two? Can this
> happen
> automatically? Should it be? Has anyone heard of cvsup
> (http://www.polstra.com/projects/freeware/CVSup/) and wether it can
> synchronize
> on the file or directory level instead of cvs module level? If it
> can
> synchronize on the file or directory level then that would be
> great. And
> if
> we could have this done automatically without too many conflicts,
> it is
> worth
> considering.
> 
> Build system - The two projects have their own build system. The
> wine
> team uses
> GNU autoconf and we use GNU make with a helper makefile. Since the
> wine
> build
> system is very posix centric and we have a customized build system,
> I
> think we
> should keep the build systems seperated. This involves maintaining
> two
> sets of
> make files, but I think it is worth it. The end result is different
> anyway,
> ReactOS DLL's ARE DLL's, whereas the wine DLL's are included in a
> big
> executable image.
> 
> Copyright - IIRC from the list discussions, we can use wine code
> without
> obtaining permission from the wine developers, but the wine
> developers
> cannot
> use ReactOS code without permission from each of the copyright
> holders.
> Does
> transferring copyright to FSF (if we decide to) change anything?
> Like,
> then the
> FSF would have to grant the wine team permission to use the code.
> 
> Wine modules that I do think is worth porting/sharing:
> 
> gdi32.dll - obviously
> icmp.dll - OS dependent
> kernel32.dll - OS dependent
> ntdll.dll - obviously
> opengl32.dll - wine specific
> user32.dll - we will have calls directly to win32k.sys
> wnaspi32.dll - OS dependent
> all winsock related modules
> 
> and the 16-bit only DLL's.
> 
> Let's discuss this topic and propose a plan for code integration to
> the
> wine developers.
> 
> - Casper
> 
> ====================================================
> = To remove yourself from this mailing list, go to =
> = http://www.reactos.com/home/mailing.html         =
> ====================================================
> 


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Sharing code with wine

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

Porting wine code seem to be the hot topic these days, so I think it is
time to discuss ways to share code with the wine project before having
ported most wine code and no (easy) way to update it in the future.

>From looking through current wine code, I see that most wine DLL's can
be shared between the two projects. There are occational references to
wine/*.h in the wine DLL modules and some of the headers in that
directory
are wine specific, but most of then are not. IMHO, it will be in the
best
interest of both projects to share Windows API DLLs wherever possible.
The reason for this is obvious; A DLL has to be implemented only once.

So what are the problems associated with such a project?

Structure - Should we move all the shared wine code into a separate
directory like reactos/wine?

It has been mentioned on the ros-kernel list to use mingw headers
instead
of having separate headers due to the fact that 1) mingw headers have a
greater chance of beeing updated more often 2) The mingw team could
benefit
from these headers (the ntddk case). Another possibillity is to have our
own
version of the Windows headers shared with wine.

I'm leaning towards the former - using mingw headers. This way may mean
more
work when updating shared wine code, because if there is a change in
public
Windows headers, both set of headers needs to be updated (wine and
mingw).
Of course, we could just do it properly from the start and implement the
full
set of Windows headers. Then this will not be a problem ;o)

Synchronization - How do we synchronize between the two? Can this happen
automatically? Should it be? Has anyone heard of cvsup
(http://www.polstra.com/projects/freeware/CVSup/) and wether it can
synchronize
on the file or directory level instead of cvs module level? If it can
synchronize on the file or directory level then that would be great. And
if
we could have this done automatically without too many conflicts, it is
worth
considering.

Build system - The two projects have their own build system. The wine
team uses
GNU autoconf and we use GNU make with a helper makefile. Since the wine
build
system is very posix centric and we have a customized build system, I
think we
should keep the build systems seperated. This involves maintaining two
sets of
make files, but I think it is worth it. The end result is different
anyway,
ReactOS DLL's ARE DLL's, whereas the wine DLL's are included in a big
executable image.

Copyright - IIRC from the list discussions, we can use wine code without
obtaining permission from the wine developers, but the wine developers
cannot
use ReactOS code without permission from each of the copyright holders.
Does
transferring copyright to FSF (if we decide to) change anything? Like,
then the
FSF would have to grant the wine team permission to use the code.

Wine modules that I do think is worth porting/sharing:

gdi32.dll - obviously
icmp.dll - OS dependent
kernel32.dll - OS dependent
ntdll.dll - obviously
opengl32.dll - wine specific
user32.dll - we will have calls directly to win32k.sys
wnaspi32.dll - OS dependent
all winsock related modules

and the 16-bit only DLL's.

Let's discuss this topic and propose a plan for code integration to the
wine developers.

- Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Unicode Library

[James T. <jim...@ad...>]

Eric Kohl wrote:
> 
> "Aliberti Emanuele" <ea...@io...> wrote:
> 
> >
> > >I finished porting unicode over to ROS. It's about 800 kbytes+ zipped.
> So,
> >
> > What is the "unicode library"?
> >
> I guess he is talking about the ansi/oem<->unicode conversion tables from
> Wine.
> 
> I'm not sure if we should use it as a dll. The main problem is that the
> conversion tables must be accessible from kernel *and* user mode. Loading
> them as a kernel mode driver will not allow us to use non-default code-page
> tables in user mode. Loading them as a dll does not allow us to use them in
> kernel mode.
> 
> IIRC, WinNT loads the default code-page tables (oem-unicode, ansi-unicode
> and unicode case-table) into a named memory section (use winobj to see them)
> and maps a view into every process. The code-page tables can also be loaded
> separately by MultiByteToWideChar() and WideCharToMultiByte(), at least I
> think they do so.
> 
> Regards,
> 
> Eric Kohl
> 
Hi,
You think I should just make a bin file or what? Put on hold?
James

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Port for Comdlg32

[Phillip S. <ps...@cf...>]

No, on 9x, they thunk down to the 16bit user.exe and gdi.exe, so our gdi32 
and user32 certainly won't run on 9x.  If we have 100% compatibility with 
the undocumented native NT api, then they should run on NT, but I don't 
think we are or ever will be compatible to that level.

At 05:30 AM 10/24/2001 -0700, you wrote:
>True with NT/2k, but is this true of '98?
>
>--- Phillip Susi <ps...@cf...> wrote:
> > because gdi32 and user32 are mostly stubs that just call into the
> > kernel.
>
>
>=====
>=======
>Frank D. Engel, Jr.
>Please note my new address: fd...@ya...

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Port for Comdlg32

[Frank D. E. Jr. <fd...@ya...>]

True with NT/2k, but is this true of '98?

--- Phillip Susi <ps...@cf...> wrote:
> because gdi32 and user32 are mostly stubs that just call into the
> kernel.


=====
=======
Frank D. Engel, Jr.
Please note my new address: fd...@ya...

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Unicode Library

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

"Aliberti Emanuele" <ea...@io...> wrote:


>
> >I finished porting unicode over to ROS. It's about 800 kbytes+ zipped.
So,
>
> What is the "unicode library"?
>
I guess he is talking about the ansi/oem<->unicode conversion tables from
Wine.

I'm not sure if we should use it as a dll. The main problem is that the
conversion tables must be accessible from kernel *and* user mode. Loading
them as a kernel mode driver will not allow us to use non-default code-page
tables in user mode. Loading them as a dll does not allow us to use them in
kernel mode.

IIRC, WinNT loads the default code-page tables (oem-unicode, ansi-unicode
and unicode case-table) into a named memory section (use winobj to see them)
and maps a view into every process. The code-page tables can also be loaded
separately by MultiByteToWideChar() and WideCharToMultiByte(), at least I
think they do so.

Regards,

Eric Kohl


====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Unicode Library

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

>I finished porting unicode over to ROS. It's about 800 kbytes+ zipped. So,

What is the "unicode library"?

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Unicode Library

[James T. <jim...@ad...>]

Hi,
I finished porting unicode over to ROS. It's about 800 kbytes+ zipped. So,
What should I do? Place it in the CVS under the lib directory?
Please advise,
James

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Re: Next version ? FORWARDING TODO LIST by Eric

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

Rex had something like this setup on mok a while back but I dont know the
url.

Steven 

-----Original Message-----
From: Robert Dickenson
To: ros...@re...
Sent: 10/23/01 9:32 PM
Subject: [ros-kernel] Re: Next version ? FORWARDING TODO LIST by Eric

At 07:03 PM 23/10/2001 +0100, you wrote:
>
>Hi
>
>When will the next version of reactos be released ? Is there a TODO
list
for version 0.0.19 ?
>
>Greetings
>Max
>
>

I was thinking about a combination between a road-map and a to-do list:


Version 0.0.18:
    - FreeLoader: int13 extensions (high priority)
    - FAT32 write support (high priority)
    - fix Gditest (medium priority)
    - ide driver split (low priority)
    - pci bus driver (optional)

Version 0.0.19:
    - FreeLoader: registry support (high priority)
    - Split ntoskrnl and hal (high priority)
    - basic cdrom support (medium priority)
    - registry write support (medium priority)
    - run user-mode services (low priority)
    - security functions (low priority)
    - usb drivers (optional)

Version 0.0.20:
    - ReactOS bootable from cdrom (high priority)
    - FreeLoader: hardware detection (high priority)
    - setup program (medium priority)
    - basic gui functionality (medium priority)
    - eventlog service (low priority)
    - smb network support (optional)
    - rtl8139 nic driver (optional)

Version 0.0.21:
    - ReactOS installable from cdrom (high priority)
    - network services (medium priority)
    - ntfs driver (low priority)
    - rpc support (low priority)
    - scandisk tool (optional)
    - ip6 support (optional)
    - pcmcia/pc-card services (optional)


Priorities:
    High: Topic must be included in release (delays release until done).
    Medium: Topic should be included in release (delays release for max
2
weeks).
    Low: Topic should be included in release (does not delay release).
    Optional: Nice to have but not needed.

Priorities of a topic can change. For example, a topic can be optional
for
one release but since it was not finished for this release, the priority
will be raised to medium because it is needed for the next release.

This can give newbies an idea where we are heading and they can choose a
low
priority or optional component for their first contribution.

- Eric

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/

[ros-kernel] Re: Next version ? FORWARDING TODO LIST by Eric

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

At 07:03 PM 23/10/2001 +0100, you wrote:
>
>Hi
>
>When will the next version of reactos be released ? Is there a TODO list
for version 0.0.19 ?
>
>Greetings
>Max
>
>

I was thinking about a combination between a road-map and a to-do list:


Version 0.0.18:
    - FreeLoader: int13 extensions (high priority)
    - FAT32 write support (high priority)
    - fix Gditest (medium priority)
    - ide driver split (low priority)
    - pci bus driver (optional)

Version 0.0.19:
    - FreeLoader: registry support (high priority)
    - Split ntoskrnl and hal (high priority)
    - basic cdrom support (medium priority)
    - registry write support (medium priority)
    - run user-mode services (low priority)
    - security functions (low priority)
    - usb drivers (optional)

Version 0.0.20:
    - ReactOS bootable from cdrom (high priority)
    - FreeLoader: hardware detection (high priority)
    - setup program (medium priority)
    - basic gui functionality (medium priority)
    - eventlog service (low priority)
    - smb network support (optional)
    - rtl8139 nic driver (optional)

Version 0.0.21:
    - ReactOS installable from cdrom (high priority)
    - network services (medium priority)
    - ntfs driver (low priority)
    - rpc support (low priority)
    - scandisk tool (optional)
    - ip6 support (optional)
    - pcmcia/pc-card services (optional)


Priorities:
    High: Topic must be included in release (delays release until done).
    Medium: Topic should be included in release (delays release for max 2
weeks).
    Low: Topic should be included in release (does not delay release).
    Optional: Nice to have but not needed.

Priorities of a topic can change. For example, a topic can be optional for
one release but since it was not finished for this release, the priority
will be raised to medium because it is needed for the next release.

This can give newbies an idea where we are heading and they can choose a low
priority or optional component for their first contribution.

- Eric

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: RE: Re: Port for Comdlg32

[James T. <jim...@ad...>]

> Steven Edwards wrote:
> 
> The source for comdlg32 and commdlg are intigrated in the wine source tree under
> wine/dlls/commdlg. I just tried to compile a few objects out of the wine source tree so that going
> to be where you will need to pull it from. Eric has said that commdlg comdlg32 and comctl32 are
> supposed to be in process of being cleaned up so it might be hard to track changes from wine to
> reactos. One last thing if you compare the .def under mingw32 for comdlg32 and the spec under
> wine, you'll notice
> 
> PrintDlgA@4
> PrintDlgExA@4     missing in mingw
> PrintDlgExW@4     missing in mingw
> PrintDlgW@4
> 
> I think the libcomdlg32.def from mingw was based on win95 where the spec for wine is based on the
> comdlg32 that ships with ie 5.01
> 
> Steven
Hi!
Okay, thanks! Phillip added info is good too! I've started playing with it right now.
Cool,
James

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Re: Port for Comdlg32

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

The source for comdlg32 and commdlg are intigrated in the wine source tree
under wine/dlls/commdlg. I just tried to compile a few objects out of the
wine source tree so that going to be where you will need to pull it from.
Eric has said that commdlg comdlg32 and comctl32 are supposed to be in
process of being cleaned up so it might be hard to track changes from wine
to reactos. One last thing if you compare the .def under mingw32 for
comdlg32 and the spec under wine, you'll notice 

PrintDlgA@4
PrintDlgExA@4     missing in mingw
PrintDlgExW@4     missing in mingw
PrintDlgW@4

I think the libcomdlg32.def from mingw was based on win95 where the spec for
wine is based on the comdlg32 that ships with ie 5.01

Steven



-----Original Message-----
From: James Tabor
To: ros...@re...
Sent: 10/23/01 5:49 PM
Subject: [ros-kernel] Re: Port for Comdlg32

> Steven Edwards wrote:
> 
> I like nicotine =P
> 
> Anyway I'm still new to programing so I've been working on notepad and
program manager from wine.
> Both of these need libcomdlg32.a from mingw to compile. I have notepad
mostly working under 98/2k.
> I'm commiting it either tonight or tommrow. Keep in mind that none of
this will do us alot of good
> untill the GDI is in better shape but if you want to go ahead with
porting comdlg32 then we can go
> ahead and start testing it and my apps under 9x/nt/2k.
> 
> Steven
> 

Hi,
Yes you need gdi32.a, shell32,, to compile comdlg32.dll, etc... I want
to build comdlg32, gdi32,
etc and test it with my Windows 98. I do not care if it breaks or what
ever! It should work like
any other dll. If it works we can tweak it for NT/2K/VP. I did this with
lz32 just to see and
it works. Still testing lz32 too.

Can you please zip it up and send comdlg32 source to me, would that be
okay too?
Thanks,
James

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/

[ros-kernel] compile under W2K?

[Davorin M. <dav...@zg...>]

Where can I get that crtdll-minigw gcc version for windows?  Only Linux =
version is listed on sourceforge.

thanks.

[ros-kernel] Re: Port for Comdlg32

[Phillip S. <ps...@cf...>]

You can probably work on comdlg32.dll on windows, but I think you'd have to 
rename it so you can link to it instead of the built in comdlg32.dll.  As 
for gdi32 and user32, you will have to use the one that comes with windows, 
because gdi32 and user32 are mostly stubs that just call into the kernel.

At 09:49 PM 10/23/2001 +0000, you wrote:
>Hi,
>Yes you need gdi32.a, shell32,, to compile comdlg32.dll, etc... I want to 
>build comdlg32, gdi32,
>etc and test it with my Windows 98. I do not care if it breaks or what 
>ever! It should work like
>any other dll. If it works we can tweak it for NT/2K/VP. I did this with 
>lz32 just to see and
>it works. Still testing lz32 too.
>
>Can you please zip it up and send comdlg32 source to me, would that be 
>okay too?
>Thanks,
>James

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: AW: Re: AW: Re: Cache and memory manager

[David W. <we...@cw...>]

On Tue, Oct 23, 2001 at 11:00:16PM +0200, Hartmut Birr wrote:
> Can I add or remove some attributes (pageable, readable or writeable) 
> to or from this section ?
> 
You should be able to by editing the linker script, ntoskrnl/ntoskrnl.lnk, 
but I thought NT treated the sections with regard to (non-)pageable just 
based on the name.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================