Re: shell32 patch 20

[Rolf Kalbermatter]

"Dmitry Timoshkov"
> "Martin Fuchs"  wrote:
> > > > Changelog:
> > > > - don't link directly to NTDLL; use MultiByteToWideChar() instead of
> > >
> > > RtlCreateUnicodeStringFromAsciiz()
> > >
> > > Why do you need that?
> >
> > RtlCreateUnicodeStringFromAsciiz() is neither present in MinGW nor in PSDK.
>
> That doesn't justify the change IMO. There are lots of places in Wine
> using that construct, and it's much more convenient and avoids code
> duplication (with a possibility of adding bugs in even such a simple
> case).

I was under the impression that it was desirable to cross compile as many
dlls as possible in different environments. shell32 has currently only a
few reasons why it can't be compiled and linked in Visual C and I think it
is a good idea to improve on that.
This of course isn't any reason but maybe an indication: native shell32 does
not import RtlCreateUnicodeStringFromAsciiz() either.

Rolf Kalbermatter
CIT Engineering Nederland BV    tel: [phone]
Treubstraat 7H                           fax: [phone]
2288 EG Rijswijk	http://www.citengineering.com
Netherlands		mailto:[e-mail]

shell32 patch 20

[Dmitry Timoshkov]

"Rolf Kalbermatter"  wrote:
> I was under the impression that it was desirable to cross compile as many
> dlls as possible in different environments.

Yes, that's a desirable task, but only if does not require to break Wine
source accomplishing it.
> shell32 has currently only a
> few reasons why it can't be compiled and linked in Visual C and I think it
> is a good idea to improve on that.

Improve, not break, or make the things uglier.
> This of course isn't any reason but maybe an indication: native shell32 does
> not import RtlCreateUnicodeStringFromAsciiz() either.

That fact actually simply proves that Wine's implementation is completely
independent from a Microsoft one, nothing more.

shell32 patch 20

[Jakob Eriksson]

Dmitry Timoshkov wrote:
> "Rolf Kalbermatter"  wrote:
> > I was under the impression that it was desirable to cross compile as many
> > dlls as possible in different environments.
>
> Yes, that's a desirable task, but only if does not require to break Wine
> source accomplishing it.

Depending on how you define break, that argument can be used to stop
almost any patch to Wine, if the goal happens to be cross compilation.

I understand your fight against code duplication and such, but IMHO cross
compilation is something that needs to happen.

We need to look at code duplication at a level not only within Wine,
but between ReactOS and Wine.  Forking a dll between projects is also a 
lot of
code duplication.

regards,
Jakob

shell32 patch 20

[Dmitry Timoshkov]

"Jakob Eriksson"  wrote:
> Depending on how you define break, that argument can be used to stop
> almost any patch to Wine, if the goal happens to be cross compilation.

What way will you decide to go, if in the next Platform SDK release
Microsoft will remove some of the existing APIs and simultaneously add
some previously undocumented? Rewrite all the affected parts of your code?
> I understand your fight against code duplication and such, but IMHO cross
> compilation is something that needs to happen.

I wonder then, how you are going to cross compile most of the kernel parts
of ReactOS code. If you would rely only on the documented APIs and headers
ReactOS would not be in the state it is now.

shell32 patch 20

[Jakob Eriksson]

Dmitry Timoshkov wrote:
> "Jakob Eriksson"  wrote:
> > Depending on how you define break, that argument can be used to stop
> > almost any patch to Wine, if the goal happens to be cross compilation.
>
> What way will you decide to go, if in the next Platform SDK release
> Microsoft will remove some of the existing APIs and simultaneously add
> some previously undocumented? Rewrite all the affected parts of your code?

I haven't thought about that. Guess we will have to consider that 
problem when it appears.
(Have they ever deprecated functions so you can't use them, by the way? 
I get warnings
on some, but it still links.)
> > I understand your fight against code duplication and such, but IMHO cross
> > compilation is something that needs to happen.
>
> I wonder then, how you are going to cross compile most of the kernel parts
> of ReactOS code. If you would rely only on the documented APIs and headers
> ReactOS would not be in the state it is now.

No, kernel parts are of course often not possible to share, since they 
are implemented on very
different subsystems:  PC hardware "API" vs UNIX system API.

But AFAIK shell32 is a user-space DLL and it should be possible to make 
it so that it can
be shared unmodified between Windows, ReactOS and Wine.
(Or VC++, mingw and wines build system.)

If I am wrong in this assumption just ignore my whole argument.

/Jakob