[PATCH] Support for Windows Mobile (on device Console)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Support for Windows Mobile (on device Console)

Andres Marin
[Code and binaries can be downloaded from
http://www.it.uc3m.es/pervasive/wce_lite_compat/ ]

Hello,

This patch makes some fixes to the last OpenSSL official version 0.9.8a.

Is well known that Microsoft WCE operating system based PDAs do not
implement text console. There are some implementations of console drivers
that allow having available a text console in Windows Mobile. The most
representative is Pocket console console driver (symbolic tools) that is
compatible with Windows CMD. Just installing Pocket Console and then
installing Windows CMD, it will work fine.

This patch allows building Openssl to be used directly in the PDA using
Pocket Console as Console driver and Microsoft CMD console interpreter as
text console. Current WCE binaries are linked against a library (wcecompat)
that redirects stdin and stdout to a host computer via active sync so unless
the PDA is plugged in the cradle OpenSSL.exe and other apps cannot be used
(since is not possible to see the output). This patch allows using a console
in the PDA and running OpenSSL applications directly as can be done in a
Windows XP operating system. (see the SCREENSHOTS)

The C flags used to build this OpenSSL version for Windows Mobile is
#ifdef WCE_ON_DEVICE_CONSOLE

This flag does not depend on the platform i.e. PocketPC, Windows Mobile...
it just distinguish among the cases when the console is installed in the PDA
or when a host computer is used to redirect the input/output.

All the information can be read in:

http://www.it.uc3m.es/pervasive/wce_lite_compat/

The files enclosed in this e-mail are:

patch_wce.txt       <-- a diff -r -2 patch to the official version
patch_wce2.txt      <-- a diff -Nru patch to the official version
INSTALL.WCE   <-- Modified version of this file (included also in zips and
patchs). That explain how to build OpenSSL in this way
*.jpg   <-- Some screenshots

Binaries for ARM can be downloaded from

http://www.it.uc3m.es/pervasive/wce_lite_compat/


Take into account that some software should be installed in your pdas if you
want to test the binaries directly.

Pocket Console http://www.symbolictools.de/public/pocketconsole/
Microsoft CMD
http://www.symbolictools.de/public/pocketconsole/applications/index.htm



Have a look at *Building with PortSDK* below these lines to understand
changes.

If you have any question about this path do not hesitate about asking:


Daniel Díaz Sánchez [hidden email]
Andrés Marin López [hidden email]

[CHANGES]

*) Add support for PDAs with no text console and compiles the major part of
OpenSSL against native libraries. For the few functions that are not
provided by Windows Mobile(PocketPC) 2003 SDK, MozCE project functions are
used.

[Daniel Díaz; Andrés Marín. Carlos III University (Spain)]


[Content of Install.WCE]


 INSTALLATION FOR THE WINDOWS CE PLATFORM
 ----------------------------------------

 There are two ways for building OpenSSL for Windows CE.

 1) If you are using a hanheld or any device with an early version of
 Windows CE must follow the instructions written  in "Building with
 WceCompat". These instructions generates binaries that are invoked
 from the host, executed in the device but the output (stdout) is
 redirected again to the host.

 Building OpenSSL for Windows CE requires the following external tools:

  * Microsoft eMbedded Visual C++ 3.0
  * wcecompat compatibility library (www.essemer.com.au)
  * Optionally ceutils for running automated tests (www.essemer.com.au)

 Windows CE support in OpenSSL relies on wcecompat and therefore it's
 appropriate to check http://www.essemer.com.au/windowsce/ for updates in
 case of compilation problems. As for the moment of this writing version
 1.1 is available and actually required for WCE 4.2 and newer platforms.
 All Windows CE specific issues should be directed to www.essemer.com.au.

 The C Runtime Library implementation for Windows CE that is included with
 Microsoft eMbedded Visual C++ 3.0 is incomplete and in some places
 incorrect.  wcecompat plugs the holes and tries to bring the Windows CE
 CRT to a level that is more compatible with ANSI C.  wcecompat goes further
 and provides low-level IO and stream IO support for stdin/stdout/stderr
 (which Windows CE does not provide).  This IO functionality is not needed
 by the OpenSSL library itself but is used for the tests and openssl.exe.
 More information is available at www.essemer.com.au.

 You also need Perl for Win32.  You will need ActiveState Perl, available
 from http://www.activestate.com/ActivePerl.

2) If you want to use Openssl applications for instance OpenSSL.exe
 from a PDA or any Windows CE based device that do not implement a text
 console (all of them) you will need the following software to use OpenSSL
 directly in the PDA:

   * Microsoft eMbedded Visual C++ 4.0
   * Pocket PC 2003 SDK (Windows CE 4.20)
   * wce_lite_compat library (www.it.uc3m.es/pervasive/wce_lite_compat)
   * Pocket Console Driver
(http://www.symbolictools.de/public/pocketconsole/)
   * Port SDK (http://www.symbolictools.de/public/pocketconsole/developers
                /portsdk.htm)
   * Microsoft CMD (can be downloaded from
http://www.symbolictools.de/public/
                        pocketconsole/applications/cmd/index.htm)

 

 The C Runtime Library implementation of Windows CE 3.0 is incomplete but
newer
 versions of Windows CE provides more functionality, so wcecompat is not
needed.
 The C Runtime Library is still incomplete but only few functions that has
been
 taked from MOZCE project that has been packed in wce_lite_compat.

 This way of compiling Windows CE for a PDA provides binaries ready to be
invoked
 form the PDA, executed in the PDA and the output of the command will be
shown in
 the PDA also, so you will have portable OpenSSL!.

 Follow the process described in "Building with PortSDK" to obtain binaries.

 
 Building with WceCompat
 -----------------------

 Setup the eMbedded Visual C++ environment.  There are batch files for doing
 this installed with eVC++.  For an ARM processor, for example, execute:

 > "C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN\WCEARM.BAT"

 Next indicate where wcecompat is located:

 > set WCECOMPAT=C:\wcecompat

 Next you should run Configure:

 > perl Configure VC-CE

 Next you need to build the Makefiles:

 > ms\do_ms

 If you get errors about things not having numbers assigned then check the
 troubleshooting section in INSTALL.W32: you probably won't be able to
compile
 it as it stands.

 Then from the VC++ environment at a prompt do:

 - to build static libraries:

   > nmake -f ms\ce.mak

 - or to build DLLs:

   > nmake -f ms\cedll.mak

 If all is well it should compile and you will have some static libraries
and
 executables in out32, or some DLLs and executables in out32dll.  If you
want
 to try the tests then make sure the ceutils are in the path and do:
 
 > cd out32
 > ..\ms\testce

 This will copy each of the test programs to the Windows CE device and
execute
 them, displaying the output of the tests on this computer.  The output
should
 look similar to the output produced by running the tests for a regular
Windows
 build.


 Building with PortSDK
 -----------------------

 Setup the eMbedded Visual C++ environment.  There are batch files for doing
 this installed with eVC++.  For an ARM processor, for example, execute:

 > "C:\Program Files\Microsoft eMbedded Tools\EVC\WCE420\BIN\WCEARM.BAT"

 Next build wce_lite_compat, form the same console (embedded C++
environment)
 goto wce_lite_compat directory

 > nmake -f Makefile

 Next indicate where PORTSDK and wce_lite_compat is located:


 > set PORTSDK_DIR=C:\PortSDK
 > set WCE_LITE_COMPAT=C:\wce_lite_compat

 
 Next you should run Configure:

 > perl Configure VC-CE_PDA_CONSOLE --openssldir=\OpenSSL\

 Next you need to build the Makefiles:

 > ms\do_ms

 If you get errors about things not having numbers assigned then check the
 troubleshooting section in INSTALL.W32: you probably won't be able to
compile
 it as it stands.

 Then from the VC++ environment at a prompt do:

 - to build static libraries:

   > nmake -f ms\cepdaconsole.mak

 - or to build DLLs:

   > nmake -f ms\cepdaconsoledll.mak

 If all is well it should compile and you will have some static libraries
and
 executables in out32, or some DLLs and executables in out32dll.  If you
want
 to try the tests then make sure the Pocket Console Driver and Microsoft CMD

 are instaled in your PDA and run:

 out32dll_ARMV4_pda_console> ..\ms\mkfile_dllcepda.bat ( for dlls )

 This bat file generates a directory structure and copy some files to it.
This
 files are in directory toPDA\, copy all the content of this directory in
your
 home directory in your PDA, so you will have:

 \OpenSSL\OpenSSL\   <- binaries
 \OpenSSL\ms\        <- test files
 \OpenSSL\test\      <- some files to help tests
 \OpenSSL\certs\     <- some example certs

 To test OpenSSL in your PDA open a console, move to \OpenSSL\OpenSSL and
run:
 > ..\ms\test_cepda.bat

wce.zip (51K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Support for Windows Mobile (on device Console)

Andy Polyakov
> [Code and binaries can be downloaded from
> http://www.it.uc3m.es/pervasive/wce_lite_compat/ ]
>
> This patch makes some fixes to the last OpenSSL official version 0.9.8a.

First of all you have to realize that we're reluctant to accept
functional patches to released code. Meaning that if you want to see
your submission in official OpenSSL distribution, then you *have to*
target HEAD branch, not 0.9.8. When we see it working in HEAD, *then*
one can discuss back-port to released code base [if of actual interest
by that time].

Now as for submission itself. As far as I can tell it essentially boils
down to following things.

1. Tiny patches for missing _IONBF definition, #define ftime _ftime, int
_fmode declaration in apps/apps.c, #include <stdlib.h> in couple of
places... All in additional #ifdef WCE_ON_DEVICE_CONSOLE/#endif.

2. wce_lite_compat which implements open/read/write/close and stat.

3. Duplicate code in VC-32.pl to allow for extra WCE_ON_DEVICE_CONSOLE
and link PortSDK, generate separate makefile for the target.


Well, I still fail to see why either is necessary. "Still" refers to the
fact I've earlier commented on submission from you, guys, in similar
manner, i.e. "why do you want to treat your target so special?" Think in
more general terms!

As for 1. I'd rather #ifndef _IONBF affected code; implement own ftime
on all CE [or use some WIN32 API on all WIN32! say GetSystemTime]; get
rid of _fmode altogether; #include <stdlib.h> unconditionally...

As for 2. I'd rather eradicate all references to open/read/write/close
as well as stat for all Windows CE. It's perfectly possible!

As for 3. I'd rather check for an environment variable, say PORTSDK, and
emit makefile which would link with it without duplicating code or
separate makefile.

This way it would be possible to reduce build instructions to "setup
either WCECOMPAT or PORTSDK environment variable, but not both, and
compile." How does it sound? A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [PATCH] Support for Windows Mobile (on device Console)

Steven Reddie
The approach I took with wcecompat and integration with OpenSSL was to make
OpenSSL have as little special knowledge of CE as possible.  This means that
wcecompat emulates missing ANSI/Posix functionality so that OpenSSL simply
continues to program to the standard interfaces.  Wcecompat should be
replaceable with very minor changes to OpenSSL, hopefully only where
$WCECOMPAT is referenced in VC-32.pl.  The submitted patches referenced in
the email below are much larger than I'd expect and so I suspect that they
were either performed on unclean trees or some files were reformatted or
saved with different end-of-line encodings (there are hugh diffs to
makefile.bak for example).  It makes it difficult to see precisely what
changes were made.

BTW, I recall that the original version of the CE support in mozilla was
using my wcecompat library, although the code looks very different now.  So
we seem to be talking about integrating two different versions of wcecompat
into OpenSSL.  Not that there's anything special about my library, but
what's the solution should a few more groups want their own CE compatibility
layer included?  Assuming they all do little more than provide the missing
ANSI/Posix functionality then the only changes they should require to
OpenSSL (above what have already been made) are to reference the new library
in VC-32.pl and select it via config/Configure.

Steven

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Andy Polyakov
Sent: Wednesday, 2 November 2005 1:03 AM
To: [hidden email]
Subject: Re: [PATCH] Support for Windows Mobile (on device Console)

> [Code and binaries can be downloaded from
> http://www.it.uc3m.es/pervasive/wce_lite_compat/ ]
>
> This patch makes some fixes to the last OpenSSL official version 0.9.8a.

First of all you have to realize that we're reluctant to accept functional
patches to released code. Meaning that if you want to see your submission in
official OpenSSL distribution, then you *have to* target HEAD branch, not
0.9.8. When we see it working in HEAD, *then* one can discuss back-port to
released code base [if of actual interest by that time].

Now as for submission itself. As far as I can tell it essentially boils down
to following things.

1. Tiny patches for missing _IONBF definition, #define ftime _ftime, int
_fmode declaration in apps/apps.c, #include <stdlib.h> in couple of
places... All in additional #ifdef WCE_ON_DEVICE_CONSOLE/#endif.

2. wce_lite_compat which implements open/read/write/close and stat.

3. Duplicate code in VC-32.pl to allow for extra WCE_ON_DEVICE_CONSOLE and
link PortSDK, generate separate makefile for the target.


Well, I still fail to see why either is necessary. "Still" refers to the
fact I've earlier commented on submission from you, guys, in similar
manner, i.e. "why do you want to treat your target so special?" Think in
more general terms!

As for 1. I'd rather #ifndef _IONBF affected code; implement own ftime
on all CE [or use some WIN32 API on all WIN32! say GetSystemTime]; get
rid of _fmode altogether; #include <stdlib.h> unconditionally...

As for 2. I'd rather eradicate all references to open/read/write/close
as well as stat for all Windows CE. It's perfectly possible!

As for 3. I'd rather check for an environment variable, say PORTSDK, and
emit makefile which would link with it without duplicating code or
separate makefile.

This way it would be possible to reduce build instructions to "setup
either WCECOMPAT or PORTSDK environment variable, but not both, and
compile." How does it sound? A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Support for Windows Mobile (on device Console)

Andy Polyakov
> The approach I took with wcecompat and integration with OpenSSL was to make
> OpenSSL have as little special knowledge of CE as possible.

And my suggestion is to identify unnecessary code in given context and
instead of striving for patching holes, just eliminate the redundant
code. E.g. [at least] in CE context I figure one can drop Unix-ish
open/read/write/close, which are used only in bss_fd.c, which in turn is
not used anywhere in OpenSSL. And most stat calls are redundant and can
be eliminated. This would elimitate need for suggested wce_lite_compat.

> This means that
> wcecompat emulates missing ANSI/Posix functionality  so that OpenSSL simply
> continues to program to the standard interfaces.

So does portsdk.

> Wcecompat should be
> replaceable with very minor changes to OpenSSL, hopefully only where
> $WCECOMPAT is referenced in VC-32.pl.

They suggest to replace it with PortSDK *and* wce_lite_compat and my
suggestion is to replace it with PortSDK *alone*. Well, "replace" is
wrong term. "*Choose* between wcecompat and portsdk" is more appropraite.

> The submitted patches referenced in
> the email below are much larger than I'd expect

Yes, the patch is total mess. It's *reverse* diff between configured
trees. As mentioned essential chanages to source are tiny and I reckon
that they can/should be generalized, most specifically I see no need to
tag them with #ifdef THIS_IS_MY_VERY_SPECIAL_TARGET.

> Not that there's anything special about my library, but
> what's the solution should a few more groups want their own CE compatibility
> layer included?  Assuming they all do little more than provide the missing
> ANSI/Posix functionality then the only changes they should require to
> OpenSSL (above what have already been made) are to reference the new library
> in VC-32.pl and select it via config/Configure.

My suggestion is to select alternative library rather through
environment variable, than through separate target lines in config. I
think one VC-CE line is enough, at least for now. Cheers. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]