Dear Michal, Dear All, Please find enclosed a win32 patch for UNICODE support, in "diff -cr orig patched" format, applying to stunnel official v502 as found here: https://www.stunnel.org/downloads/stunnel-5.02.tar.gz.

This patch mainly addresses UNICODE compilation issues for Win32 target.

It is a first step in my usual port to WCE system, that I decided to "split" in two steps (to make it more clear for Michal code reviewing) : 1/ fix win32 code to UNICODE support, just for win32 (ie Windows Desktop version) 2/ fix specific WCE issues (to come in the near future)

To compile for Win32 I use VC++ 9.0 Express Edition on an XP sp2 host system.

The present stunnel patch addresses the following issues :

************* I] COMPILATION FAILURES

It is important to state that to detect more type mismatching (that can be error prone at runtime), I delibarately use /WX option on my W32 compiler: this flag takes each warning as an error.

This is very useful for UNICODE clean coding as, without this option, the compiler will just warn when seeing a short* (unicode string) used as a char* (ansi string), which leads to big pb at run time.

1/ vc.mak : I added a trivial support for a new "makew32" command line option to activate UNICODE compilation. So that to compile for W32 WITH UNICODE, one has just to type :

makew32 "UNICODESUPPORT="

(Note : in the MS nmake world, this syntax is equivalent to /DUNICODESUPPORT in eg borland make.)

To compile for ANSI, just type : makew32 on the command line, as usual, with no option.

Added /WX flag for strict type checking (very helpful to track abusive/error prone casts).

Added _CRT_NON_CONFORMING_SWPRINTFS to avoid compilation errors about _stprintf in ui_win_gui.c: MS has changed the prototype of the function and the FLAG is required to activate the old fashion interface that is used in the stunnel code.

2/ makew32.bat : Just added a comment to mention how to call the script to compile for UNICODE.

makew32 "UNICODESUPPORT="

3/ resolver.c : UNICODE strings are required for : LoadLibrary (so use TEXT macro for literals)

4/ ui_win_gui.c UNICODE strings are required for :

GetModuleFileName (see Winmain), SetCurrentDirectory (so that stunnel_exe_path and "c" variable must be TCHAR) so we have to use _tcsrchr instead of strchr, _tcscmp instead of strcmp and TEXT() macro for "c" variable affectation.

_tputenv_s must also be used instead of _putenv_s

SERVICE_NAME literal must be UNICODE because of "serviceTable[0].lpServiceName" struct member used by StartServiceCtrlDispatcher. Also for CreateService, OpenService, RegisterServiceCtrlHandler,

str_printf requires special format spec flag "%ls" for WIDE CHAR strings, and "%hs" for explicit ANSI CHAR strings. It is better, for the symetry of the code, to explicitely state %ls or %hs for each situation.

Prototype error : service_install function HAS DIFFERENT prototypes at the top of the source file and in the body of the source file : the correct prototype, considering the rest of the code using this function, is the... pure ANSI one ...

GetModuleFileNameEx (in enum_windows) requires that window_exe_path be UNICODE (TCHAR).

in edit_config function : ShellExecute requires UNICODE strings

5/ ui_win_cli.c

In main function : UNICODE required by GetModuleFileName and SetCurrentDirectory. then we have to use TCHAR for "c" and stunnel_exe_path variables, and use : _tcsrchr _tputenv_s accordingly.

************* II] OPERATIONAL ERRORS or IMPROVMENTS (at run-time)

1/ MINOR IMPROVMENT : replaced some "default" win3.1 style ugly bold fonts by thinner fonts (as those appearing on the MAIN WINDOW MENU text items). See resources.rc, About and Password dlgboxes :

Explicit use of FONT << 8, "MS Sans Serif" >>

I am not an artist but I think good to have consistant look between menus and dlgboxes, and to look like a little bit different than win3.1...

************************** III] TODO list and WISH LIST list for win32 target :

1/ win32 makefile : _CRT_NON_CONFORMING_SWPRINTFS flag to <<avoid>> in makefile, so that we have to clarify the ui_win_gui.c code on that point

2/ mingw32 makefile : 2.1 add UNICODE flag support in mgw32 makefile. 2.2 check the interest of _CRT_NON_CONFORMING_SWPRINTFS

3/ ui_win_cli.c :

shoudn't we use s_log instead of fprintf(stderr) ?

***************

I hope you will find this patch useful.

More fixes are coming very soon for WCE5.0/WM6 support (my own WCE version is now finished and working, but I have to clean my code a little before submitting it).

Yours sincerely,

Pierre Delaage

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

Le 23/06/2014 18:48, Pierre DELAAGE a écrit :

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 by comparison with the original 502 version (as found here: 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.

COMPILATION Environments :

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.

SUMMARY of bugs/fixes :

For WCE:

WCE COMPILATION BUGS :

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 Many "A" version of some system services are just missing : 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 RUNTIME BUGS & fixes :

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.

WCE COMPILATION ADDS (evc.mak) :

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 COMPILATION BUGS :

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.

W32 COMPILATION ADDS (in vc.mak) :

Added explicit link to comctl32.lib (for InitCommonControls() call that I added to win_gui.c).

W32 RUN-TIME BUGS / Improvments :

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 the log panel : 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 "?".

W32-RT03 : in win-gui.c, UNICODE printf format specs : EVERY printf using a TCHAR variable is now using a UNICODE/ANSI FORMAT STRING (#define'd) for explicit format specification for TCHAR strings : 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...

WISH LIST :

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

W002 : CONF LOADING and icon files : 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

---

For WCE:

WCE COMPILATION BUGS or fixes :

1/ common.h : no shfolder.h include file in WCE; (if needed, we will find a workaround for ShGetFolderPath in WCE)

2/ client.c : 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

lpCmdline type on WCE : 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 expects a char* so that we need another conversion function : "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.

'AllocateAndInitializeSid' undefined: '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.

errno_t and _tputenv_s() undefined : redefined in mywcedefs.h/.c source file

'GetMenuItemCount' undefined: This call does not exist in WCE. it is used to test the end of a menu destruction loop: 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.

6/ InterlockedExchange not defined for X86 or Emulator targets : 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 RUNTIME bugs & fixes :

WCE-RT01 : CommandBar_InsermenuBar DOES NOT create the log window menu

At run-time CommandBar_InsermenuBar just fails with this error on WM6 phones or emulator :

"CommandBar_InsertMenubar: error 120: This function is only valid in win32 mode"

After many investigations this message has two causes : 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"", BUT on WM6.1.4 emulator the message is different ! it is : "CommandBar_InsertMenubar: error1004: Invalid flags" So that I was searching for an explanation in the wrong direction for a while.. FIX: in resources.rc : suppress the HELP flag, I say the FLAG, in the "&help" menu item of the main menu definition in the resources.rc file. in evc.mak : 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.

CAUSE : dixit MSDN, commandbars DO NOT resize automatically: 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