apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject RE: APR WCE take 3
Date Tue, 12 Feb 2002 10:12:42 GMT
> -----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." <wrowe@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
As WCE lacks some concepts from 'standard' platforms, like console and
all the things related to it, like concept of drives, environment,

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

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.


View raw message