reactos-kernel

[ros-kernel] Re: Unicode Library

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

I thought the translation tables were in the *.nls files, which were mapped 
into memory as needed?

At 03:08 AM 10/25/2001 +0000, you wrote:

>Hi Eric,
>Okay, I believe the unicode goes into kernel32.dll as "codepage"'s. I'm using
>a Process Explorer and a Dll Explorer to verify this. Yeah!  What should I
>do? Write it into the kernel32.dll?
>James

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

[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] 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: 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] 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] 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 All!
Is there anyone else other than me porting wine to ROS? I have made some
progress. I'm working on shlwapi and comctl32 for now. Wow what a mess!
With shlwapi, I've moved headers in to the local directory instead of placing
them in the include/wine. Worry about that later. Browsing through the
wine headers is a chore.

Need help with windres, anyone have good examples of adding texted bin
code in the rc files? ~Icon stuff~.

Remember this is not a futile effort, the objective is to have a gui up
and running for the gui/apps programmers. For me, this is a quick way to
learn Windows after purposely avoiding it for so long..


Thanks,
James

====================================================
= 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...>]

> -----Original Message-----
> From: jim...@ad... 
> [mailto:jim...@ad...] 
> Sent: 26. oktober 2001 16:52
> To: ros...@re...
> Subject: [ros-kernel] Re: Sharing code with wine
> 
> 
> Hi All!
> Is there anyone else other than me porting wine to ROS?

I'm looking into it.

> I'm working on shlwapi and comctl32 for now. Wow what a mess!

You're right about that!

> With shlwapi, I've moved headers in 
> to the local directory instead of placing them in the 
> include/wine. Worry about that later. Browsing through the 
> wine headers is a chore.

I'm trying to use the wine DLL's with minimal changes to the
code and headers. There are all sorts of problems
with the headers under mingw.

I've put the wine code (from CVS) into a directory parallel
to ReactOS. Then I will create makefiles compatible with
the ReactOS build system.

If you're changing the wine headers, please make sure that you
can easily update the ReactOS version from the wine version in
the future. Possibly ask the wine people if a restructuring is
OK with them.

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

Casper,
You can remove the debug stuff from the wine source and replace it with
ros debug. Replace TRACE with DPRINT and add ros #define NDEBUG than 
#include <debug.h>. That's one of the most simple things to do. We do not
need wine debug headers at all. Based on what I know~~~
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

[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: 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 Eric,
Okay, I believe the unicode goes into kernel32.dll as "codepage"'s. I'm using
a Process Explorer and a Dll Explorer to verify this. Yeah!  What should I
do? Write it into the kernel32.dll?
James

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

[ros-kernel] Re: Unicode Library

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

At 08.53 25/10/2001 -0400, you wrote:
>I thought the translation tables were in the *.nls files, which were 
>mapped into memory as needed?

Some of them are mapped right during boot. Put the boot-time /SOS switch to 
see it, they're the first thing the loader reads after the kernel, the hal, 
the system hive and the VGA font

For those who don't beleive how nls tables are loaded, get objdir (NT DDK) 
or WinObj (from Sysinternals) and have a look into the \NLS directory

====================================================
= 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...>]

"KJK::Hyperion" <no...@li...> wrote:


> At 08.53 25/10/2001 -0400, you wrote:
> >I thought the translation tables were in the *.nls files, which were
> >mapped into memory as needed?
>
> Some of them are mapped right during boot. Put the boot-time /SOS switch
to
> see it, they're the first thing the loader reads after the kernel, the
hal,
> the system hive and the VGA font

In my local source tree I changed the hardcoded translations in ntoskrnl.exe
(rtl/nls.c) to a table driven concept. As soon as the memory pools are
available the default translation tables are allocated and initialized.
Although this doesn't change much, we can load the .nls files later, update
the table pointers and free the old buffers. Of course this must happen
before smss is started.

Btw, the german win2k loads:
    c_1252.nls (ansi codepage)
    c_850.nls (oem codepage)
    l_intl.nls (???)

- Eric Kohl


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

[ros-kernel] Re: Unicode Library

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

What is the format of nls files?  They don't appear to be PE files.

At 08:03 PM 10/25/2001 +0200, you wrote:
>At 08.53 25/10/2001 -0400, you wrote:
>>I thought the translation tables were in the *.nls files, which were 
>>mapped into memory as needed?
>
>Some of them are mapped right during boot. Put the boot-time /SOS switch 
>to see it, they're the first thing the loader reads after the kernel, the 
>hal, the system hive and the VGA font
>
>For those who don't beleive how nls tables are loaded, get objdir (NT DDK) 
>or WinObj (from Sysinternals) and have a look into the \NLS directory

====================================================
= 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...>]

"Phillip Susi" <ps...@cf...> wrote:

> What is the format of nls files?  They don't appear to be PE files.
>
There is a format description at:  http://webcenter.ru/~kazarn/eng/nls.htm

It describes the format of the codepage files (c_xxx.nls). Locale.nls seems
to contain the locale information for all listed countries (detailed format
unknown). Unicode.nls seems to contain the unicode upcase and lowercase
tables (detailed format unknown).

Any more details??

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

Phillip Susi wrote:
> 
> I thought the translation tables were in the *.nls files, which were mapped
> into memory as needed?

Loaded by NTLDR at startup and demand loaded by NTOSKRNL.EXE?

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