Created attachment 15530 [details]
Patch for sal/

mh->hro: is somebody of your team able to do the requested review ?

Accepted.

Not for OOo 2.0

vq@hro: Did you realize that this is a working but ugly patch for the really
existing and compilable cws_srx645_mingw branch?
You are not expected to put a lot of effort in it, but some comments/hints
would have been helpfull.

This is a proof of concept branch that is not supposed to get integrated as
is, so the Target OOo Later makes no sense at all, but a little help
in the last four months would have been appreciated.

hro@vq: I already did a lot of support in the past but there are such things as
priorities. So if it's working on SRX645 why was the target OOo 2.0 ?

Just a few general comments:

All those DEFINE_UNICOWS_THUNK statements in ResolveThunk.cpp make the exports
unmaintainable as exporting was done through forward exporting uwinapi.dxp and
unicows.dxp.  I would appreciate a tool that generates intermediate output.


FindFirstVolumeW.cpp (FindNext... etc.) VolumeName is an output parameter so
LPCWSTR is wrong (though the linker ignores this, as the mingw header files do
not seem to contain FindFirstVolume etc.).

BTW: Uwinapi and unicows, was this ever tested on Windows9x/Me ? I can't find a
modification in solenv in wnt.mk that makes uwinapi the first library linked
against every module. Seems to me as alll the changes in uwinapi are useless, as
they will never be used.

In sal/inc/sal/types.h sal_Unicode is not "typedefed" to wchar_t. But instead
the code in osl is fragmented with #ifdef _MINGW32__ and cast statements to
convert from sal_Unicode to wchar_t and vice versa.

The global constructor destructor problem is solved in dllentry.c even for mingw
but when sal is linked dllentry is excluded for mingw. Does not make sense.

At some locations (tempfile.cxx) _alloca is replaced with malloc() and free(). I
feel this was just because _alloca was used in a macro that uses structured
exception handling (__try, __except) but _alloca should be availiable with mingw
too and is much faster and  better to maintain.

> hro@vq: I already did a lot of support in the past but there are such things as
> priorities.
He, don't kill the messenger ;) Klang vermutlich viel unfreundlicher als es
gemeint war :)

> So if it's working on SRX645 why was the target OOo 2.0 ?
Propably an oversight on my side.

This is tono's patch, I hope he can have a look at your comments. Thanks.

tono -> hro, vq
Thanks for your comments, hro.

I do not think DEFINE_UNICOWS_THUNK statements will cause major difficulties 
in exports maintenance in the future. I would expect no further enhancement in 
unicows.dll by Microsoft. Therefore, I think making a tool to generate them is 
not necessary. If they cause difficulties in maintaining uwinapi exports, it 
would be better to slpit them out into another C source I think.

Uwinapi and unicows are working on Windows9x/Me. They are linked before 
kernel32/user32 and tested my myself and thirano.

Dllentry is excluded for mingw because it is included in a SLB file cpposl.lib.

I will comment on issues in Find.*VolumeW, sal_Unicode and alloca in this 
weekend after testing your suggestions because I do not remember details why I 
did not do so :-P

tono -> hro, vq

I have done several tests.
MinGW does have Find.*VolumeW in its headers. So the right solution is to 
patch the MinGW header instead of patching FindFirstVolumeW.cpp.

I have tested alloca and it works with MinGW.

The issue of sal_Unicode is a bit complecated. In MSVC wchar_t is a typedef of 
unsigned short int, but it is not true in gcc. The sal project can be built 
with defining sal_Unicode as wchar_t and it will eliminate many castings but 
it will generate many casting requirements where we assign ushort value to 
sal_Unicode.
IMHO it might be safer to define sal_Unicode as unisigned short because it 
will limit the needs for casting in calling WIN32APIs and MSVCRT functions.

I would appreciate your comments.

I have tried "#define sal_Unicode wchar_t".

It seems to work well with WIN32APIs. I had to patch several headers including 
a jsdk header but it seems to be less work than "#define sal_Unicode wchar_t".

One critical issue is expat. Expat has a compile definition flag to switch XML 
characters among char, unsigned short and wchar_t. The latter two are for 
unicode characters but if we choose wchar_t, logging character, which normally 
is char type, also defined to be wchar_t type and source comment says that it 
would be encoded in UTF-16.

To avoid complicated situation, I am choosing to define unicode xml character 
as unsinged short and get compromised with "reinterpret_cast".

ToDo:
Split unicows thunking code out of ResolveThunk.cpp


Takashi Ono (tono)

Outdated and obsolete issue.

Closed

Created attachment 73784