Re: sysparams: slight optimisation for IDA 3

[Dmitry Timoshkov]

"Andrew de Quincey"  wrote:
> Version 3
> - spi_idx = SPI_GETICONTITLELOGFONT;
> -
> - if (!spi_loaded[spi_idx])
> - {
> - memcpy(lpLogFont, &iconTitleLogFont, sizeof(LOGFONTA));
> - break;
> - }

Sorry to bother you again, but probably the comparison statement
needs to be reverted...

sysparams: slight optimisation for IDA 3

[Andrew de Quincey]

> Sorry to bother you again, but probably the comparison statement
> needs to be reverted...

Doh! You're right. Fixed in yet another patch. Gah

As for bothering.. no problems! The sooner I know what coding styles etc are 
acceptable the better.

Splitting out shared Win16/Win32 code

[Casper Hornstrup]

Dlls/winmm/lolvldrv.c has a function (MMDRV_Message) shared by the
Win16 and the Win32 implementation of mmsystem. Since it is shared
by both mmsystem.dll and winmm.dll, all Win16 APIs used in the shared
functions will be imported by the Win32 implementation (winmm.dll)
also. On ReactOS no such APIs exist so the library will not load.

I see two immediate solutions:

1) Check with a preprocessor variable and not compile the Win16 part
of the shared Win16/Win32 functions when --disable-win16 is specified.

2) Duplicate the shared code in a Win32 specific file and Win16
specific file.

How should it be handled?

Casper Hornstrup

Splitting out shared Win16/Win32 code

[Steven Edwards]

Hello Capser,

--- Casper Hornstrup  wrote:
> Dlls/winmm/lolvldrv.c has a function (MMDRV_Message) shared by the
> Win16 and the Win32 implementation of mmsystem. Since it is shared
> by both mmsystem.dll and winmm.dll, all Win16 APIs used in the shared
> functions will be imported by the Win32 implementation (winmm.dll)
> also. On ReactOS no such APIs exist so the library will not load.

Yup there are a few places where you will see this problem, Winmm,
comdlg32 and some spots in User and GDI. The User and GDI parts are not
that big of a deal for the ReactOS port though. We can pick and chose
code snips as needed.
> I see two immediate solutions:
> - Check with a preprocessor variable and not compile the Win16 part
>
> of the shared Win16/Win32 functions when --disable-win16 is
> specified.

I like this method but it adds a few more Ugly #ifdefs to the code. We
need to keep these changes as small as possible.
> - Duplicate the shared code in a Win32 specific file and Win16
>
> specific file.

It submitted a patch for this problem a while back in comdlg32 and it
went to the silent void that is Alexandres patch rejection que....
http://www.winehq.org/hypermail/wine-patches/2003/10/0265.html
> How should it be handled?

Alexandre?

Thanks
Steven

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Splitting out shared Win16/Win32 code

[Alexandre Julliard]

Steven Edwards  writes:
> It submitted a patch for this problem a while back in comdlg32 and it
> went to the silent void that is Alexandres patch rejection que....
> http://www.winehq.org/hypermail/wine-patches/2003/10/0265.html

Can't say that I remember that patch, I must have dropped it. Could
you please resumit?
> > How should it be handled?

Wherever possible, by having the 16-bit code call the 32-bit code.
Where this is really not possible, by duplicating the necessary code,
but that should be the last resort. There is no #ifdef we can use for
that purpose, and we shouldn't add one.

Splitting out shared Win16/Win32 code

[Dimitrie O. Paun]

On November 29, 2003 03:59 pm, Casper Hornstrup wrote:
> - Duplicate the shared code in a Win32 specific file and Win16
>
> specific file.

I haven't looked if the code can be duplicated, but by the size
of the function (it's not big), I'd say duplicating is the way
to go (added bonus if by doing so we can simplify a bit each of them).

Splitting out shared Win16/Win32 code

[Eric Pouech]

Casper Hornstrup wrote:
> Dlls/winmm/lolvldrv.c has a function (MMDRV_Message) shared by the
> Win16 and the Win32 implementation of mmsystem. Since it is shared
> by both mmsystem.dll and winmm.dll, all Win16 APIs used in the shared
> functions will be imported by the Win32 implementation (winmm.dll)
> also. On ReactOS no such APIs exist so the library will not load.

I don't see any 16 bit (exported from mmsystem.dll) function called from 
this MMDRV_Message function. Could you elaborate a bit more ?
winmm should be able to be compiled without the mmsystem support (the 
contrary is not correct, but you don't need it in ROS AFAICT).
A+

Splitting out shared Win16/Win32 code

[Casper Hornstrup]

> -----Oprindelig meddelelse-----
> Fra: Eric Pouech [mailto:[e-mail]] 
> Sendt: 30. november 2003 16:35
> Til: Casper Hornstrup
> Cc: 'wine-devel'
> Emne: Re: Splitting out shared Win16/Win32 code
>
> Casper Hornstrup wrote:
> > Dlls/winmm/lolvldrv.c has a function (MMDRV_Message) shared by the 
> > Win16 and the Win32 implementation of mmsystem. Since it is
>
> shared by
> > both mmsystem.dll and winmm.dll, all Win16 APIs used in the shared 
> > functions will be imported by the Win32 implementation (winmm.dll) 
> > also. On ReactOS no such APIs exist so the library will not load.
>
> I don't see any 16 bit (exported from mmsystem.dll) function 
> called from 
> this MMDRV_Message function. Could you elaborate a bit more ? 
> winmm should be able to be compiled without the mmsystem support (the 
> contrary is not correct, but you don't need it in ROS AFAICT).
> A+

You're right. I should have written MMDRV_PhysicalFeatures.
See attached patch.

Casper

Splitting out shared Win16/Win32 code

[Eric Pouech]

> You're right. I should have written MMDRV_PhysicalFeatures.
> See attached patch.

ooops, I forgot to submit the fix I had for that back to wine...
This should be a better fix, whithout code duplication

A+

Splitting out shared Win16/Win32 code

[Casper Hornstrup]

Great. I have a few more patches at http://212.242.245.122/patches/.
Maybe you can review them?

Casper
> -----Oprindelig meddelelse-----
> Fra: [e-mail] 
> [mailto:[e-mail]] På vegne af Eric Pouech
> Sendt: 30. november 2003 20:57
> Til: Casper Hornstrup
> Cc: [e-mail]; [e-mail]
> Emne: Re: Splitting out shared Win16/Win32 code
> > You're right. I should have written MMDRV_PhysicalFeatures. See 
> > attached patch.
>
> ooops, I forgot to submit the fix I had for that back to 
> wine... This should be a better fix, whithout code duplication
> A+
>
> Eric Pouech

Splitting out shared Win16/Win32 code

[Dimitrie O. Paun]

On December 2, 2003 03:40 am, Casper Hornstrup wrote:
> Great. I have a few more patches at http://212.242.245.122/patches/.
> Maybe you can review them?

It's better to post them on the list. More people get to see them,
they get indexed by various search engines, and they get archived
for posterity. If you're not sure about them, post them on wine-devel
for discussion. If you think they can go it, post them to wine-patches,
people who care will see them, and comment if need be.