Discussion:
[stunnel-users] public domain [PATCH] to stunnel v502 for WCE/W32: WCE port + a few fixes for W32
(too old to reply)
Pierre DELAAGE
2014-08-17 16:38:16 UTC
Permalink
Dear Michal, Dear All,
I resend my full patch from 2014/06/23 just having modified an erroneous
gpl'ed licensing text in the new source files "mywcedefs.h" and
"mywcedefs.c", that are wce platform compatibility files.

I confirm that I release the full patch, include those two new source
files, to the public domain.

The patch is provided BOTH in an incremental version patch2/patch1 since
my UNICODE "patch1" W32 only version (from the 2014/06/09), and in
cumulative form patch2/orig ("patch0to2....txt") by comparison with the
original 502 version (as found here:
https://www.stunnel.org/downloads/stunnel-5.02.tar.gz).

More details below in my original mail from the 2014/06/23.

This patch is still relevant for application to stunnel v503 official
version:
it brings full UNICODE supports to WIN32 and WCE versions,
and makes stunnel compile for and run on WCE devices fixing various
issues described below.

Yours sincerely,
Pierre Delaage
Dear Michal, Dear All,
Please find enclosed a WCE/win32 patch that fixes various compilation
and runtime bugs both for WCE and, in a smaller amount, for W32.
The patch is provided BOTH in an incremental version patch2/patch1
since my "patch1" W32 only version, and in cumulative form patch2/orig
https://www.stunnel.org/downloads/stunnel-5.02.tar.gz).
Both patches are given in "diff -cr old new" format,
with old="v502-orig OR patch1" and new=patch2.
==========================
To compile for WCE, I use MS EVC4 sp4 (free) + WCE SDK 420 on an XP
sp2 host system.
To compile for Win32, I use VC++ 9.0 (2008) Express Edition on an XP
sp2 host system.
=======================
========
----------------------
WCE-CC01 (UNICODE version) : The sw simply does not compile because of
lack fo some W32 specific services on WCE: ShellExecute,
GetCurrentDirectory ....
See complete list further in that mail.
WCE-CC02 : ANSI support
CreateFileA,GetModuleFileNameA, GetMessageA,DispatchMessageA,
CreateEventA, CreateWindowExA,RegisterClassA ,LoadCursorA ,LoadIconA,
PostMessageA, DefWindowProcA,DialogBoxIndirectParamA, FindResourceA,
SetWindowTextA, SendDlgItemMessageA,SendMessageA, GetSaveFileNameA,
InsertMenuA , LoadImageA, LoadMenuA, FormatMessageA,MessageBoxA
They can be easily rewritten from WCHAR version,
but I did not have time to do that.
Moreover, as UNICODE version supersedes ANSI version (I mean : "does
the same and even more"), there is no urgent need for a pure ANSI
version for WCE.
Anyway, I did my best to have a code, except missing "A" services,
that compiles for both context.
Note that for W32, the code can be compiled either for ANSI or UNICODE.
--------------------------
WCE-RT01 : the log window menu is NOT created (by
CommandBar_InsermenuBar)
WCE-RT02 : Log Window stays empty : there is no display of the log
file content
WCE-RT03 : When resizing or Changing the screen orientation (on some
smartphones) from portrait to landscape and vice/versa, the commandBar
DOES NOT resize properly to fit the main window size.
WCE-RT04 : When playing with CUSTOM file-icons (with some new code),
and when A COMMUNICATION SERVICE IS CHANGING in STATUS, the matching
ICON resources (for taskbar) are automatically deleted from the system
memory so that, at a time, icons are just disappearing from the TASKBAR.
Note: this is not happening with DEFAULT icons loaded from rc file.
WCE-RT05 : With small screens phones, the main (log window) menu DOES
NOT display completely on the screen: the menu labels are too large.
WCE-RT06 : conf file CANNOT be opened AND/OR read although there is NO
security restriction (and while it can be read by older v434 stunnel
version !): this is due to a change in CreateFile flags.
---------------------------------
Removed /MT flags for X86 and emulator targets : that flag is NOT
supported on WCE although CL.EXE for WCE is EXACTLY the same tool as
CL.EXE for "VC6.0 for Pentium I/II cpus". Indeed, for WCE targets,
there is no libcmt nor msvcrt libs on the target systems, for which
/MT flags (or /MD) are leading the app to be linked to.
Those flags are only meaningful when CL targets a win32-Desktop platform.
Flags replaced for X86/emulator targets by explicit linking to
corelibc and coredll libs AND "/NODEFAULTLIBS" flag.
For other targets: as "/NODEFAULTLIB coredll.lib corelibc.lib" is
ALSO a good lib list for any wce cpu, the option /MC (that means
exactly the same) is just redundant and I removed it, just to have
exactly the same LD flags for all WCE targets.
For W32
=======
----------------------
W32-CC01 : "makeW32 clean" DOES NOT clean anything.
CAUSE : it's because of 3 typos in vc.mak: in clean rule the letter
"O" is missing from the variable names "GUI-O-BJS" and "NOGUI-O-BJS";
also there is a BAD "slash" instead of a backslash in the "fd.obj"
file name in SHAREOBJS list (that slash does not prevent compilation,
but prevents DEL command working).
FIX : typos corrected.
----------------------------------
Added explicit link to comctl32.lib (for InitCommonControls() call
that I added to win_gui.c).
---------------------------------
W32-RT01 : on classic XP theme, there is no separation between the
menu of the main window and the client zone, giving the window a poor
flat look (while usually other apps display a 3D inside border).
FIX : in win-gui.c, replaced CreateWindow by CreateWindowEx, with
exactly the same parameters except the first, which is a
WS_EX_STATICEDGE style bit giving 3D border to the client window in
edit_handle=CreateWindowEx(WS_EX_STATICEDGE....
W32-RT02 : with large screens, the Help menu is just too far to the
right when every other command are grouped to the left.
On most of recent apps, the ? button is back to "the rightest"
position on the ...LEFT menubar, NOT on the rightest position on the
app window that can be very large.
FIX : removed the HELP flag in resources.rc, as for WCE. and replaced
the label by just a "?".
EVERY printf using a TCHAR variable is now using a UNICODE/ANSI FORMAT
because the compiler is NOT able to detect any inconsistency between
type of data, and format spec, missing this FORMAT SPECS may lead to
really bad behaviors...(reading a wstrinf as a char * just give a one
car string...).
Remember : %s is %ls for WCHAR, and in fact %hs for "ansi" in ANSI
printf. I repeat : for <<ANSI>>-printf that is used intensively even
in UNICODE version of stunnel.
W32-RT04 : on Win32 Desktop, when Service version is installed, the
"display name" of the stunnel service in the "Windows Service Control
Manager" is just a minimalistic lower caps string "stunnel", while it
could be more explicit.
In ui_win_gui.c I declared another UNICODE string for that,
SERVICE_DISPLAY_NAME, which is valued to "Stunnel SSL wrapper", and
kept "stunnel" as an internal service name used as a "key" to identify
the service in the local service database.
W32-RT05 : on Win32 Desktop, When Service version is installed, it is
missing some "description" of stunnel service in the "Windows Service
Control Manager".I think stunnel deserves a more professional
description: lack of description may lead to think that stunnel
service may be something un-desireable...
I added one that is CUSTOMIZABLE as a resource in resources.rc.
IDS_SERVICE_DESC "SSL encryption wrapper between local/remote clients
and local/remote servers"
This can be changed easily, and also localized if needed later...
===========
W001 : the doc should mention, for icon files, that they MUST be
".ico" files for W32 version, and ".bmp" files for WCE.(indeed BMP are
NOT working for W32; adding support for them for w32 would be trivial
with my fully w32-compatible WCE code, while ".ico" support for WCE
would require some extra work...).
If an icon file is missing and/or in an improper format, stunnel just
stops ! I consider that it should just log a message and continue with
default icons...
W003 : In Win_gui.c : "return TRUE" on processed WM_XXXX messages is
just wrong most of the time.
This should be replaced by "return 0", dixit MSDN.
Yes, I know, this is not logical but it is like this...
********************************************************************
DETAILED FIXES description for WCE
********************************************************************
========
-------------------------------
no shfolder.h include file in WCE; (if needed, we will find a
workaround for ShGetFolderPath in WCE)
parse_socket_error : a return is missing at line 933. Strange to note
that VC++ 2009 did not see that bug, while the old EVC4 compiler can
see it.
3/ protocol.c(538)
missing return at the end of imap_server().
4/ ui_win_gui.c
on WCE, lpCmdline is ALWAYS WCHAR, even in <<ANSI>> compilation mode
that is (hardly) possible on WCE, so that WCE ALWAYS need a "WCHAR to
STR conversion", but in ANSI mode tstr2str INAPPROPRIATELY here
"wstr2str", see extra source in mywcedefs.c.
The lack of this routine gives a compilation error in WCE-ansi mode
(WCE-ANSI will require more investigation later ...).
'_tputenv_s' undefined : rewritten for WCE in mywcedefs.c
'InsertMenuItem' undefined : replaced by InsertMenu both for WCE and W32
'MIIM_STRING' : undeclared identifier
'MFS_GRAYED' : undeclared identifier
Although menuiteminfo exists on WCE, some flags DO NOT, and all the
code using menuiteminfo is useless in WCE by the lack of InsertMenuItem.
Anyway all this menu items insertion code has been replaced by a more
simple way to insert menuitems, common to W32/WCE, by using
traditional Win32 syntax (InsertMenuItem replaced by InsertMenu).
'LR_LOADFROMFILE' : undeclared identifier
Although it is mentioned in MSDN library, this flag does NOT exist in
WCE winuser.h, and it is USELESS to declare it the same it is in w32
SDK: this does not work.
Consequently the WCE LoadImage is NOT able to load images <<from
files>>, so I offer a replacement, built on WCE SHLoadBitmap,
defined in the new WCE companion file "mywcedefs.c": I have called
that function "wceLoadIconFromFile".
This routine is able to load a 16x16 bitmap file (bmp extension) into
an HICON win32 object.
Please note that it only supports ".BMP" files, NOT ".ico" files. That
code can be used on W32 if needed (I tested it : it works).
'ShellExecute' undefined : rewritten for WCE in mywcedefs.c, on top of
ShellExecuteEx.
'FreeSid' undefined;
On WCE, the user is always admin, so all the isAdmin() code is useless
and has been put in #ifndef _WIN32_WCE: on WCE, isAdmin() always
returns TRUE.
redefined in mywcedefs.h/.c source file
This call does not exist in WCE.
it is easier and W32/WCE full compatible to just test the result of
deleteItem(item 0) to stop the destruction loop.
GetCurrentDirectory does not exist in WCE : reimplemented in
mywcedefs.c on top of GetModuleFileName.
5/ ui_win_cli.c
_tputenv_s needs a WCE implementation : provided by mywcedefs.c
str2tstr expects a LP(C)STR, not a "const char *" : explicit cast is
necessary from char* to LPSTR.
the CC flag /Dx86 was missing in evc.mak for those targets.
WCE LINKING ERRORS
------------------
options.obj : error LNK2001: unresolved external symbol WSAGetLastError
network.obj : error LNK2001: unresolved external symbol WSAGetLastError
stunnel.obj : error LNK2019: unresolved external symbol
WSAGetLastError referenc
ed in function daemon_loop
ctx.obj : error LNK2001: unresolved external symbol WSAGetLastError
client.obj : error LNK2001: unresolved external symbol WSAGetLastError
log.obj : error LNK2001: unresolved external symbol WSAGetLastError
log.obj : error LNK2019: unresolved external symbol WSASetLastError
referenced i
n function s_log
..\bin\ARMV4\stunnel.exe : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
FIX : evc.mak : link to winsock2 ws2.lib instead of old winsock.lib (!)
--------------------------
WCE-RT01 : CommandBar_InsermenuBar DOES NOT create the log window menu
At run-time CommandBar_InsermenuBar just fails with this error on WM6
"CommandBar_InsertMenubar: error 120: This function is only valid in
win32 mode"
1/ HELP flag on menu resources, although documented in WCE SDK 420, is
NOT supported on WCE !
2/ On WM6 emulator, the message is ""CommandBar_InsertMenubar: error
120: This function is only valid in win32 mode"",
"CommandBar_InsertMenubar: error1004: Invalid flags"
So that I was searching for an explanation in the wrong direction for
a while..
suppress the HELP flag, I say the FLAG, in the "&help" menu item of
the main menu definition in the resources.rc file.
modified to define _WIN32_WCE flag for RC compilation, so that we can
get different codes for WCE than W32 on some menus definition.
WCE-RT02 : Log Window stays empty : there is no display of the log
file content.
CAUSE : on WCE WM_SHOWINDOW is NOT generated on "ShowWindow" call.
This msg DOES NOT exist in WCE MSDN, and EVEN IF it is really declared
in include files !,
it is NOT produced on WCE devices/emulators.
FIX: both for W32 and WCE, use WM_WINDOWPOSCHANGED message that is
generated in the same circumstances.
Nota: some better typing of "visible" as a BOOL is coded, fully
consistent with MSDN WM_SHOWWINDOW or IsWindowVisible() specs.
Also I use explicitely the IsWindowVisible() function that is more
reliable than the content of the WM_WINDOWPOSCHANGED msg to detect
changes in visibility (many tests with that on WCE/W32).
WCE-RT03 : When resizing or Changing the screen orientation (on some
WM6 smartphones with sliding keyboards) from portrait to landscape and
vice/versa, the commandBar DOES NOT resize properly to fit the main
window size.
FIX: still dixit MSDN, some explicit TB_AUTOSIZE message must be sent
to the commandBar on WM_SIZE on the main window, and AddAdornements
must also be repeated,
to get a good redraw of the commandbar.
WCE-RT04 : When playing with CUSTOM file-icons (with some new code),
and when A COMMUNICATION SERVICE IS CHANGING STATE, the matching ICON
resources (for taskbar) are automatically deleted from the system
memory so that, at a time, icons are just disappearing from the TASKBAR.
Note: this is not happening with DEFAULT icons loaded from rc file.
FIX : for WCE we have to Duplicate an Icon before the system drops it
down when it replaces it by another icon.
Unfortunately, win32 "DuplicateIcon()" does NOT exist on WCE so...I
rewrote it, in mywcedefs.c. Shortly speaking : by drawing an old Icon
with transparency on some bitmap that I can feed to
CreateIconIndirect() to re-create a duplicate icon.
Also, to be sure of the stability of the icon destruction behavior...I
PERFORM it myself explicitely before asking the system to replace it !
That code is also compatible with W32 (but I kept it only active for
WCE).
WCE-RT05 : With small screens phones, the main menu DOES NOT display
completely on the screen, and the HELP and CLOSE commands are not
accessible on the commandbar.
FIX : in resources.rc I changed some menuitem labels to something
shorter..."HELP" is now "?" which is something quite standard nowadays...
WCE-RT06 : conf file CANNOT be opened AND/OR read while there is NO
security restriction (and while it can be read by older v434 stunnel
version !)
CAUSE: in file.c some rewrite of the file_open() function has occurred
in some revision of the code, using some "SECURITY TOKEN ACCESS"
"sophisticated" flags instead of the good old GENERIC r/w flags. Those
new sophisticated flags are just messing things deeply on WCE, and
possibly on some W32 platforms. Although the file opens with no
errors, subsequent Read operations are just failing.
FIX : file.c, file_open() has been RESTORED to its good old code with
GENERIC_READ and GENERIC_WRITE flags.
***************
I hope you will find this W32/WCE patch useful.
Yours sincerely,
Pierre Delaage
z***@gmail.com
2016-04-14 04:07:00 UTC
Permalink
Hi Pierre,

Thanks so much for working on this patch. Will try it to see how far I can go to get this to work on a WINCE 6.5/7.0 handheld.

I have STunnel 4.15 working, but need TLS 1.2 connectivity. I am having a hell of a time getting FIPS/SSL to compile correctly with VC 2008/C++ 4.0 with STunnel 5.31.

Will keep you posted...

Loading...