-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Guys,
Please feel free to try the beta version I just made available for download:
https://www.stunnel.org/downloads/beta/stunnel-5.04b1.tar.gz https://www.stunnel.org/downloads/beta/stunnel-5.04b1-installer.exe
The list of changes includes most of the issues recently discussed on the stunnel-users mailing list and more.
* New features - Support for local mode ("exec" option) on Win32. - A more explicit service description provided for the Windows SCM (thx to Pierre Delaage). - TCP/IP dependency added for NT service in order to (hopefully) prevent initialization failure at boot time. - FIPS canister updated to version 2.0.8 in the Win32 binary build.
* Bugfixes - load_icon_default() modified to return copies of default icons instead of the original resources to prevent the resources from being destroyed. - Reportedly more compatible values used for the dwDesiredAccess parameter of the CreateFile() function (thx to Pierre Delaage). - Partially merged UNICODE compilation fixes (thx to Pierre Delaage). - Partially merged Windows CE patches (thx to Pierre Delaage). - Fixed typos in stunnel.init.in and vc.mak. - Fixed incorrect memory allocation statistics update in str_realloc(). - Missing REMOTE_PORT environmental variable is provided to processes spawned with "exec" on Unix platforms. - Taskbar icon is no longer disabled for NT service.
Some basic examples for local mode ("exec" option) on Windows:
; Service based on a command-line tool [netstat] accept = 8015 exec = c:\windows\system32\netstat.exe execargs = netstat -a
; Remote cmd.exe protected with SSL ; Certificate-based authentication needs to be configured here! [cmd] accept = 1337 exec = c:\windows\system32\cmd.exe
Mike
Dear Michal, Thanks for the update.
At least I can state that as long as the rc file will keep the "HELP" flag in WCE, the WCE main window will fail to load its entire main menu. this flag is clearly not supported on WCE.
So that, for example, access to log file will be impossible.
Moreover, on small devices, this flag is improper (apart from the fact it is not working...): its purpose is just to move the help menu to the top right corner of the main window : then, because of other menu items texts that are much too large on small devices, the help menu goes away outside the screen.
So that finally, and even on wider screens, I highly suggest to remove that flag and to shorten some menu texts (eg replace "&Help" by "&?", "certificates" by "certs.").
Unicode : Be careful not to take unicode patch "partly" because many pieces of codes are relying one on the other, sometimes indirectly (eg through sprintf). It was not obvious to track all of the modifications in 502.
I will check other stuff later.
Yours sincerely, Pierre
Le 16/09/2014 18:16, Michal Trojnara a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Guys,
Please feel free to try the beta version I just made available for download:
https://www.stunnel.org/downloads/beta/stunnel-5.04b1.tar.gz https://www.stunnel.org/downloads/beta/stunnel-5.04b1-installer.exe
The list of changes includes most of the issues recently discussed on the stunnel-users mailing list and more.
New features
- Support for local mode ("exec" option) on Win32.
- A more explicit service description provided for the Windows SCM (thx to Pierre Delaage).
- TCP/IP dependency added for NT service in order to (hopefully) prevent initialization failure at boot time.
- FIPS canister updated to version 2.0.8 in the Win32 binary build.
Bugfixes
- load_icon_default() modified to return copies of default icons instead of the original resources to prevent the resources from being destroyed.
- Reportedly more compatible values used for the dwDesiredAccess parameter of the CreateFile() function (thx to Pierre Delaage).
- Partially merged UNICODE compilation fixes (thx to Pierre Delaage).
- Partially merged Windows CE patches (thx to Pierre Delaage).
- Fixed typos in stunnel.init.in and vc.mak.
- Fixed incorrect memory allocation statistics update in str_realloc().
- Missing REMOTE_PORT environmental variable is provided to processes spawned with "exec" on Unix platforms.
- Taskbar icon is no longer disabled for NT service.
Some basic examples for local mode ("exec" option) on Windows:
; Service based on a command-line tool [netstat] accept = 8015 exec = c:\windows\system32\netstat.exe execargs = netstat -a
; Remote cmd.exe protected with SSL ; Certificate-based authentication needs to be configured here! [cmd] accept = 1337 exec = c:\windows\system32\cmd.exe
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQYYkoACgkQ/NU+nXTHMtGmfwCfSdHFmK8q5IRcS/CoFmYMZ40G zUEAoNUrIp0KAJ4+0LPwx+/1lJG6q2q/ =aSXM -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Pierre,
Be careful not to take unicode patch "partly"
Unfortunately applying a single huge patch makes the code hard to maintain and occasionally breaks some features that are not used by the author of the patch.
because many pieces of codes are relying one on the other, sometimes indirectly (eg through sprintf).
Honestly, I don't like the idea of using format strings that are clearly documented by Microsoft as obsolete and likely to be incompatible with future versions of Windows.
When compiled with MinGW it results with the following warnings: ui_win_gui.c: In function ‘edit_config’: ui_win_gui.c:1117:17: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c: In function ‘service_install’: ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 3 has type ‘LPSTR’ [-Wformat]
It was not obvious to track all of the modifications in 502.
Quoting Linus: https://www.kernel.org/doc/Documentation/SubmittingPatches
<begin of quote>
3) Separate your changes.
Separate _logical changes_ into a single patch file.
For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. If your changes include an API update, and a new driver which uses that new API, separate those into two patches.
On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch.
If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description.
If you cannot condense your patch set into a smaller set of patches, then only post say 15 or so at a time and wait for review and integration.
<end of quote>
Mike
I understand... But at least for compilation issues, it is useless to submit one patch if the whole app STILL does NOT compile because of (many) other pbs.
For runtime bugs such as unicode : many little pieces of code are bound: partly fix means bugs remains and global app remain un-usable and un-predictable because mixing erroneous code and partial fix.
so...global philosophy is one thing...practical fixing another....
Regards Pierre
Le 16/09/2014 19:25, Michal Trojnara a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Pierre,
Be careful not to take unicode patch "partly"
Unfortunately applying a single huge patch makes the code hard to maintain and occasionally breaks some features that are not used by the author of the patch.
because many pieces of codes are relying one on the other, sometimes indirectly (eg through sprintf).
Honestly, I don't like the idea of using format strings that are clearly documented by Microsoft as obsolete and likely to be incompatible with future versions of Windows.
When compiled with MinGW it results with the following warnings: ui_win_gui.c: In function ‘edit_config’: ui_win_gui.c:1117:17: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c: In function ‘service_install’: ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 3 has type ‘LPSTR’ [-Wformat]
It was not obvious to track all of the modifications in 502.
Quoting Linus: https://www.kernel.org/doc/Documentation/SubmittingPatches
<begin of quote>
- Separate your changes.
Separate _logical changes_ into a single patch file.
For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. If your changes include an API update, and a new driver which uses that new API, separate those into two patches.
On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch.
If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description.
If you cannot condense your patch set into a smaller set of patches, then only post say 15 or so at a time and wait for review and integration.
<end of quote>
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQYcoIACgkQ/NU+nXTHMtF/FgCg4vB2Oxo6v2GakR+qcuPPP83K h20AoNqJ6jqWVaVAL1belyXquUySXMku =5kyk -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Dear Michal,
Le 16/09/2014 19:25, Michal Trojnara a écrit :
Honestly, I don't like the idea of using format strings that are clearly documented by Microsoft as obsolete and likely to be incompatible with future versions of Windows.
Ok...but I think you are and I am "partly" wrong : the interest of %hc/%lc or %hs/%hS was that they ARE STABLE in MEANING whatever you use printf or wprintf: for example %lc always interprets and prints a supposed wide char as ...a wide char, not a couple of ansi chars.
ie : those syntax are MUCH MORE CLEAR and EXPLICIT than just using "%s" or "%S" whose meanings are CHANGING whether you compile for unicode or not.
Anyway...I checked the standard C libc and it appears that %hc and %hs are NOT ISO C99 standard compliant while %lc and %ls are... See that pdf : http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf page 405-406 and here : http://www.gnu.org/software/libc/manual/html_node/Table-of-Output-Conversion...
***** Finally, it is easy to redefine the format_specs strings I gave in my v502 patch to correct values: so just remove the "h" letter in my ansi specs...and LET the "l" letter in my unicode format specs. *****
NOTE : this is where your MINGW warnings come from : in standard C, the %h prefix is reserved to numerical types, not string/char types. I do hope that you compiled with MinGW defining some UNICODE flag, and that MINGW knows how to deal with TCHAR... because, even if I can make mistakes, I am not a newbie and carefully checked those FORMAT_STRINGS : both for ansi and unicode in all the various possible cases...so that I did not see at once what was the problem with the mingw compiler...but now I think the issue with it is around numerical misinterpretation of wchars/wstrings due to my abusive use of "%h" flag...
Provided that we know what we are doing and get some code, with appropriate #define, that unambiguously formats Wide strings/chars as wide, and ansi as such, we can choose between various solutions. I prefer to use explicit FORMAT_STRINGS than obscuring the code by doubling any printf line, taking the risk to misuse some %l flag or, worsely, to play dangerously with %s and %S, because both can be used BOTH with printf and wprintf and CHANGE (I should say : REVERT) their meaning in ANSI and UNICODE compilation context.
Whatever you take the problem, you have to have different format_specs strings for unicode or ansi strings printf.
Regards Pierre
Le 16/09/2014 19:25, Michal Trojnara a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Pierre,
Be careful not to take unicode patch "partly"
Unfortunately applying a single huge patch makes the code hard to maintain and occasionally breaks some features that are not used by the author of the patch.
because many pieces of codes are relying one on the other, sometimes indirectly (eg through sprintf).
Honestly, I don't like the idea of using format strings that are clearly documented by Microsoft as obsolete and likely to be incompatible with future versions of Windows.
When compiled with MinGW it results with the following warnings: ui_win_gui.c: In function ‘edit_config’: ui_win_gui.c:1117:17: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c: In function ‘service_install’: ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 3 has type ‘LPSTR’ [-Wformat]
It was not obvious to track all of the modifications in 502.
Quoting Linus: https://www.kernel.org/doc/Documentation/SubmittingPatches
<begin of quote>
- Separate your changes.
Separate _logical changes_ into a single patch file.
For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. If your changes include an API update, and a new driver which uses that new API, separate those into two patches.
On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch.
If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description.
If you cannot condense your patch set into a smaller set of patches, then only post say 15 or so at a time and wait for review and integration.
<end of quote>
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQYcoIACgkQ/NU+nXTHMtF/FgCg4vB2Oxo6v2GakR+qcuPPP83K h20AoNqJ6jqWVaVAL1belyXquUySXMku =5kyk -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Pierre DELAAGE wrote:
the interest of %hc/%lc or %hs/%hS was that they ARE STABLE in MEANING whatever you use printf or wprintf
I agree. I finally decided to get rid of them, but for a different reason: there is no way (as far a I could find) to specify the code page for text conversion with %S/%hs/%hS.
I believe I managed to get stunnel 5.04 fully Unicode compatible. UTF-8 is used for the configuration file and logs. GUI uses UTF-16 for its internal operations when compiled with -DUNICODE, which is the default now.
Best regards, Michal Trojnara
Hi Mike,
Are you sure the stunnel-5.04b1.tar.gz file includes all changed files since 5.03 release?
I ran a diff between 5.03 and. 5.04 (just for the src directory) and I found no changed C files... But version.h changed :)
Maybe some cats were left out of the bag?
Thanks.
-----Original Message----- From: Michal Trojnara [email protected] Sender: "stunnel-users" [email protected] Date: Tue, 16 Sep 2014 18:16:10 To: [email protected][email protected]; [email protected] Subject: [stunnel-users] stunnel beta (5.04b1) is available for testing
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Guys,
Please feel free to try the beta version I just made available for download:
https://www.stunnel.org/downloads/beta/stunnel-5.04b1.tar.gz https://www.stunnel.org/downloads/beta/stunnel-5.04b1-installer.exe
The list of changes includes most of the issues recently discussed on the stunnel-users mailing list and more.
* New features - Support for local mode ("exec" option) on Win32. - A more explicit service description provided for the Windows SCM (thx to Pierre Delaage). - TCP/IP dependency added for NT service in order to (hopefully) prevent initialization failure at boot time. - FIPS canister updated to version 2.0.8 in the Win32 binary build.
* Bugfixes - load_icon_default() modified to return copies of default icons instead of the original resources to prevent the resources from being destroyed. - Reportedly more compatible values used for the dwDesiredAccess parameter of the CreateFile() function (thx to Pierre Delaage). - Partially merged UNICODE compilation fixes (thx to Pierre Delaage). - Partially merged Windows CE patches (thx to Pierre Delaage). - Fixed typos in stunnel.init.in and vc.mak. - Fixed incorrect memory allocation statistics update in str_realloc(). - Missing REMOTE_PORT environmental variable is provided to processes spawned with "exec" on Unix platforms. - Taskbar icon is no longer disabled for NT service.
Some basic examples for local mode ("exec" option) on Windows:
; Service based on a command-line tool [netstat] accept = 8015 exec = c:\windows\system32\netstat.exe execargs = netstat -a
; Remote cmd.exe protected with SSL ; Certificate-based authentication needs to be configured here! [cmd] accept = 1337 exec = c:\windows\system32\cmd.exe
Mike
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[email protected] wrote:
Are you sure the stunnel-5.04b1.tar.gz file includes all changed files since 5.03 release?
Argh. I indeed copied the wrong file. My mistake. Thank you for reporting it. I corrected the stunnel-5.04b1.tar.gz file.
Mike
Much better like this for RC file both for WCE and W32 ! I will check the menu space taken on a real phone and let you know later.
Pierre
Le 16/09/2014 22:40, Michal Trojnara a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[email protected] wrote:
Are you sure the stunnel-5.04b1.tar.gz file includes all changed files since 5.03 release?
Argh. I indeed copied the wrong file. My mistake. Thank you for reporting it. I corrected the stunnel-5.04b1.tar.gz file.
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQYoD4ACgkQ/NU+nXTHMtHv6ACfcqL//tSfU3I5JsJeMUchIBun A1wAoIHQuGy5+pVx0apCSHsH9VKqeVZk =AgTb -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Dear Michal, it appears that the extra files wcedefs.h/.c, required for WCE port, are missing from your repository :
in ui_win_gui.c, "wceLoadIconFromFile()" is used, but not defined anywhere...
Regards Pierre
Le 16/09/2014 22:40, Michal Trojnara a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[email protected] wrote:
Are you sure the stunnel-5.04b1.tar.gz file includes all changed files since 5.03 release?
Argh. I indeed copied the wrong file. My mistake. Thank you for reporting it. I corrected the stunnel-5.04b1.tar.gz file.
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQYoD4ACgkQ/NU+nXTHMtHv6ACfcqL//tSfU3I5JsJeMUchIBun A1wAoIHQuGy5+pVx0apCSHsH9VKqeVZk =AgTb -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Dear Michal, It appears that 5.04b1 is not UNICODE compatible.
Anyway, the first compilation issue reproduced below is not new...and you will find the proper code to fix it in my 502 complete, and extensively documented, patch.
I think it can help that I send you my complete 502 source tree, which will make easier for you to read the "patched" code in a coherent bunch of files, instead of damaging your eyes in reading an obscure text patch file with diff/ed instructions. I will send it soon directly to you.
I understand that my patch is big, this is why I splitted it in two main parts : unicode for w32 on one side (that was a separate patch), then WCE support on another side (provided in two forms : one cumulating with the first patch, the other incremental). But for each big subject, to get a consistent application vs compilation and/or runtime, many little modifications (except the two big functions isolated in wcedefs.h/.c) MUST be fixed and put together in the same code. What is the interest of an incomplete patch that leaves the application UN-compilable and/or UN-runnable and so ...UN-testable ? none
To document the TWO big patches, my v502 report is written in little chapters, one issue after the other, describing the bug and the fix separately.
I will not redo all that job extensively here, there will be nothing new.
Hope anyway it will help.
I would mention also that your vc.mak is not allowing any possibility to compile with UNICODE support : this is the first thing to do, and once again you will find the proper fix in my 502 patch.
cl /MD /W3 /O2 /nologo /WX /DUNICODE -D_UNICODE /I"C:\Users\standard\Do cuments\Dvts\Contrib\openssl\v1.0.2-stable-SNAP-20121213\patch1\inc32" /I"C:\Use rs\standard\Documents\Dvts\Contrib\openssl\v1.0.2-stable-SNAP-20121213\patch1\in c32" -Fo..\obj\win32\ui_win_gui.obj -c ..\src\ui_win_gui.c ui_win_gui.c ..\src\ui_win_gui.c(177) : error C2220: avertissement consid'r' comme une erreur - aucun fichier 'object' g'n'r' ..\src\ui_win_gui.c(177) : warning C4133: 'fonction' : types incompatibles - de 'char [260]' à 'LPWCH' ..\src\ui_win_gui.c(194) : warning C4133: 'fonction' : types incompatibles - de 'char [260]' à 'LPCWSTR' ..\src\ui_win_gui.c(210) : warning C4133: 'fonction' : types incompatibles - de 'LPSTR' à 'LPTSTR' ..\src\ui_win_gui.c(241) : warning C4133: 'fonction' : types incompatibles - de 'char [260]' à 'LPWSTR' ..\src\ui_win_gui.c(1168) : warning C4028: paramètre formel 1 différent de la dé claration NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN \cl.EXE"' : code retour '0x2' Stop.
Yours sincerely Pierre
Le 16/09/2014 18:16, Michal Trojnara a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Guys,
Please feel free to try the beta version I just made available for download:
https://www.stunnel.org/downloads/beta/stunnel-5.04b1.tar.gz https://www.stunnel.org/downloads/beta/stunnel-5.04b1-installer.exe
The list of changes includes most of the issues recently discussed on the stunnel-users mailing list and more.
New features
- Support for local mode ("exec" option) on Win32.
- A more explicit service description provided for the Windows SCM (thx to Pierre Delaage).
- TCP/IP dependency added for NT service in order to (hopefully) prevent initialization failure at boot time.
- FIPS canister updated to version 2.0.8 in the Win32 binary build.
Bugfixes
- load_icon_default() modified to return copies of default icons instead of the original resources to prevent the resources from being destroyed.
- Reportedly more compatible values used for the dwDesiredAccess parameter of the CreateFile() function (thx to Pierre Delaage).
- Partially merged UNICODE compilation fixes (thx to Pierre Delaage).
- Partially merged Windows CE patches (thx to Pierre Delaage).
- Fixed typos in stunnel.init.in and vc.mak.
- Fixed incorrect memory allocation statistics update in str_realloc().
- Missing REMOTE_PORT environmental variable is provided to processes spawned with "exec" on Unix platforms.
- Taskbar icon is no longer disabled for NT service.
Some basic examples for local mode ("exec" option) on Windows:
; Service based on a command-line tool [netstat] accept = 8015 exec = c:\windows\system32\netstat.exe execargs = netstat -a
; Remote cmd.exe protected with SSL ; Certificate-based authentication needs to be configured here! [cmd] accept = 1337 exec = c:\windows\system32\cmd.exe
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQYYkoACgkQ/NU+nXTHMtGmfwCfSdHFmK8q5IRcS/CoFmYMZ40G zUEAoNUrIp0KAJ4+0LPwx+/1lJG6q2q/ =aSXM -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pierre DELAAGE wrote:
It appears that 5.04b1 is not UNICODE compatible.
It wasn't intended to be...
Anyway, the first compilation issue reproduced below is not new...and you will find the proper code to fix it in my 502 complete, and extensively documented, patch.
Thank you.
I think it can help that I send you my complete 502 source tree, which will make easier for you to read the "patched" code in a coherent bunch of files, instead of damaging your eyes in reading an obscure text patch file with diff/ed instructions. I will send it soon directly to you.
Thank you. I have received it. I'm comfortable reading patches.
My plan is to start with UNICODE. Hopefully this feature will make it to stunnel 5.04.
Thank you very much for your help with stunnel.
Best regards, Mike
-
josealf＠rocketmail.com -
Michal Trojnara -
Pierre DELAAGE