You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2002/02/10 19:30:31 UTC
APR WCE take 3
My last patch to enable WCE builds need to patch the 36 files to get things
work.
I took a slightly different approach.
Instead of applying patches to those files (mostly for the reason of missing
API calls), I've created couple of additional files which purpose is to
either recreate the missing API calls, either by reimplementing them or
returning FALSE/NULL and setting the error message .
There are tree major parts of this patch.
1. The missing CRT calls (time, strftime, errno, assert, ...) and missing
header files( created as dummy)
2. The missing API calls (some wrapped like LoadLibraryA, etc...)
3. Lightweight console GUI (implements gets, puts, getch, printf, ...)
The major advantage of this approach is that you only need to patch the 3
files, and there you go.
The rest (cca 70KB) can be downloaded from:
http://apache.mappingsoft.com/downloads/wce.zip
MT.
Index: apr_private.h
===================================================================
RCS file: /home/cvspublic/apr/include/arch/win32/apr_private.h,v
retrieving revision 1.29
diff -u -r1.29 apr_private.h
--- apr_private.h 29 Jan 2002 07:11:25 -0000 1.29
+++ apr_private.h 10 Feb 2002 18:10:29 -0000
@@ -68,6 +68,12 @@
*/
#include "apr.h"
+#ifdef _WIN32_WCE
+#include <wincrypt.h>
+#include "wcertime.h"
+#include "wcertapi.h"
+#endif
+
/*
* Add a _very_few_ declarations missing from the restricted set of headers
* (If this list becomes extensive, re-enable the required headers above!)
Index: networkio.h
===================================================================
RCS file: /home/cvspublic/apr/include/arch/win32/networkio.h,v
retrieving revision 1.20
diff -u -r1.20 networkio.h
--- networkio.h 16 Jul 2001 20:37:00 -0000 1.20
+++ networkio.h 10 Feb 2002 18:10:32 -0000
@@ -58,6 +58,13 @@
#include "apr_network_io.h"
#include "apr_general.h"
+#ifdef _WIN32_WCE
+#include <wincrypt.h>
+#include "wcertime.h"
+#include "wcertapi.h"
+#undef except
+#endif
+
struct apr_socket_t {
apr_pool_t *cntxt;
SOCKET sock;
Index: getuuid.c
===================================================================
RCS file: /home/cvspublic/apr/misc/win32/getuuid.c,v
retrieving revision 1.6
diff -u -r1.6 getuuid.c
--- getuuid.c 13 Apr 2001 15:31:31 -0000 1.6
+++ getuuid.c 10 Feb 2002 18:11:29 -0000
@@ -62,6 +62,13 @@
#include "apr.h"
#include "apr_uuid.h"
+#ifdef _WIN32_WCE
+#include <wincrypt.h>
+#include "wcertime.h"
+#include "wcertapi.h"
+#undef except
+#endif
+
APR_DECLARE(void) apr_uuid_get(apr_uuid_t *uuid)
{
GUID guid;
Re: APR WCE take 3
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Monday, February 11, 2002 8:24 PM
> Finally, I don't have a ton of time, and I'd love to see these finished this
> month. Others understand Win32 sockets API as well if not better than I, so
> I'm attaching the network aspects of your patch for seperate review.
>
> Would a Win32 committer care to review the attached network_io patches
> from Mladen for style, consistency and correctness? Deep understanding
> of WinCE isn't necessary, if you ASSURE that the patch does NOT change
> the behavior on other Win32 platforms :)
If you step up to take on this project, please ignore;
Index: shmem/win32/shm.c
===================================================================
RCS file: /home/cvspublic/apr/shmem/win32/shm.c,v
retrieving revision 1.9
diff -u -r1.9 shm.c
--- shmem/win32/shm.c 28 Jan 2002 15:56:08 -0000 1.9
+++ shmem/win32/shm.c 29 Jan 2002 14:43:00 -0000
in the patch. That's a patch I'd like to personally review and comment on
(and apply in some form.) All the rest of the patches are specific to the
network_io components of apr.
RE: APR WCE take 3
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> Sent: Tuesday, February 12, 2002 3:31 AM
> To: dev@apr.apache.org
> Subject: Re: APR WCE take 3
>
> From: "William A. Rowe, Jr." <wr...@covalent.net>
> Sent: Monday, February 11, 2002 8:24 PM
>
> > Going back to take two...
> > Some need more review. I'm uncomfortable with one aspect
> or another
> > of your choices in porting in such module patches - so I'll post
> > questions to the list and your attention on those points. But that
> > takes significantly more time to either reassure myself they are
> > fine-as-is, or post the question on how we should approach them.
> >
> > Some are outright wrong. I'll post those as well with detailed
> > explanation of the underlying issues. Again, it takes more
> time than
> > I have tonight.
Epur si muove !!!
Of course there are couple (I hope not too much :) of wrong thing in
those patches, for example MoveFile which needs to be preceded by
DeleteFile to simulate the MoveFileEx.
On the other hand MoveFileEx has a bug on WIN9x platforms (you have to
call it twice if 8.3 filenames are identical, see the MSDN).
Other issues needs some implementation discussion (or if you wish
strategic).
As WCE lacks some concepts from 'standard' platforms, like console and
all the things related to it, like concept of drives, environment,
etc...
Should we rewrite those to behave like on WIN32, rewrite to behave as
close as possible, or state as not implemented?
> I should have added a last category, before you panic. There
> are a number of the WinCE patches which make me question the
> design or correctness of
> the existing apr code. Those patches I myself will do all
> the correction work while fixing the underlying bogosity we
> had when you started hacking WinCE :)
>
> Bill
Yes, I agree. Take for example the strftime. The WCE lacks time support
in the coredll entirely. On the other hand you have to preparse the
strftime for WIN32 to be cross-platform compatible.
If you look at my take3 patches I've used the OpenBSD strftime and
ported it on WIN platform. This is perhaps too much over helming, and if
at some point Microsoft add that support to WCE it will be unneeded, but
makes one to think twice (at least me).
Other aspect is using API calls that are basically shortcuts to some
functionality like for example GetSystemTimeAsFileTime, or mentioned
MoveFileEx.
Finally, my primary testing was to assure that the patches doesn't
interfere with the existing WIN32 code, and to isolate all the missing
or unsupported functionality.
The testing was hard to do because of vivid changed of the core apr
itself. When I started that last year, I found myself manually rewriting
things over and over.
So when the code isolation will be made and included inside the core
apr, then we could go and fix the bugger.
MT.
Re: APR WCE take 3
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Monday, February 11, 2002 8:24 PM
> Going back to take two...
>
> I'm reviewing and committing so changes to occur fairly shortly don't create
> extra hassles later applying these patches.
>
> Some are trivial, some are very close to rights. I'm committing those tonight.
>
> Some need more review. I'm uncomfortable with one aspect or another of your
> choices in porting in such module patches - so I'll post questions to the
> list and your attention on those points. But that takes significantly more
> time to either reassure myself they are fine-as-is, or post the question on
> how we should approach them.
>
> Some are outright wrong. I'll post those as well with detailed explanation
> of the underlying issues. Again, it takes more time than I have tonight.
I should have added a last category, before you panic. There are a number
of the WinCE patches which make me question the design or correctness of
the existing apr code. Those patches I myself will do all the correction work
while fixing the underlying bogosity we had when you started hacking WinCE :)
Bill
Re: APR WCE take 3
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
Going back to take two...
I'm reviewing and committing so changes to occur fairly shortly don't create
extra hassles later applying these patches.
Some are trivial, some are very close to rights. I'm committing those tonight.
Some need more review. I'm uncomfortable with one aspect or another of your
choices in porting in such module patches - so I'll post questions to the
list and your attention on those points. But that takes significantly more
time to either reassure myself they are fine-as-is, or post the question on
how we should approach them.
Some are outright wrong. I'll post those as well with detailed explanation
of the underlying issues. Again, it takes more time than I have tonight.
Finally, I don't have a ton of time, and I'd love to see these finished this
month. Others understand Win32 sockets API as well if not better than I, so
I'm attaching the network aspects of your patch for seperate review.
Would a Win32 committer care to review the attached network_io patches
from Mladen for style, consistency and correctness? Deep understanding
of WinCE isn't necessary, if you ASSURE that the patch does NOT change
the behavior on other Win32 platforms :)
Bill
From: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Sunday, February 10, 2002 11:05 PM
> From: "Mladen Turk" <mt...@mappingsoft.com>
> To: <de...@apr.apache.org>
> Cc: "William A. Rowe, Jr." <wr...@covalent.net>
> Sent: Sunday, February 10, 2002 12:30 PM
> Subject: APR WCE take 3
>
>
> > My last patch to enable WCE builds need to patch the 36 files to get things
> > work.
>
> That's fine :)
>
> So I'm still slogging through those 36 files, individually, to prevent us
> from introducing errors like the 'Global\' name-prefix patch did to locks.c.
> (We forgot to consider unnamed locks.)
>
> Yes - it takes more time this way - it will be month end before I'm 100%
> finished applying your entire patch set. But it is clearer, and will greatly
> benefit any future hacking.
Re: APR WCE take 3
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Mladen Turk" <mt...@mappingsoft.com>
To: <de...@apr.apache.org>
Cc: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Sunday, February 10, 2002 12:30 PM
Subject: APR WCE take 3
> My last patch to enable WCE builds need to patch the 36 files to get things
> work.
That's fine :)
> I took a slightly different approach.
>
> Instead of applying patches to those files (mostly for the reason of missing
> API calls), I've created couple of additional files which purpose is to
> either recreate the missing API calls, either by reimplementing them or
> returning FALSE/NULL and setting the error message .
>
> There are tree major parts of this patch.
> 1. The missing CRT calls (time, strftime, errno, assert, ...) and missing
> header files( created as dummy)
> 2. The missing API calls (some wrapped like LoadLibraryA, etc...)
> 3. Lightweight console GUI (implements gets, puts, getch, printf, ...)
>
> The major advantage of this approach is that you only need to patch the 3
> files, and there you go.
I have a big issue - using the headers masks the implementation of APR from
APR implementors - that's badness. We want the code to be concise, but more
importantly, to be understood by grocking the module in question (be it the
dir.c, strings.c, md5.c, whatever.)
Hiding failures and missing implementations in a 'side car' header will make
it more difficult for future implementors to extend and complete.
So I'm still slogging through those 36 files, individually, to prevent us
from introducing errors like the 'Global\' name-prefix patch did to locks.c.
(We forgot to consider unnamed locks.)
Yes - it takes more time this way - it will be month end before I'm 100%
finished applying your entire patch set. But it is clearer, and will greatly
benefit any future hacking.
Once again, thanks for the porting effort and submissions! This is a really
terrific demonstration that APR can accomplish somewhat unexpected things :)
Bill