Re: Ok...

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>The namespacing thing is done. It introduced some problems, though (namely
>with ppfDirEntry and ppf_DirEntry). The serialization stuff, I haven't

ppfDirEntry should become ::ppfDirEntry (it's part of the API), while
ppf_DirEntry should become ::pp::internal::DirEntry

ppfDirEntry is defined in PenguinFile.h

>-I've removed some std:: prefixes to some standard library global functions
>(ie, C functions). It might be a good idea to do the std::, but it didn't
>compile. I think we should instead include the ::std namespace into
>::pp::internal. That way, stuff always work. We use a different naming
>convention than the standard library, so we shouldn't run into name clashes.

Sounds good.

>-I removed this code from ppf_GlobablData.cpp:
>
>#if HAVE_UNISTD_H
>#  include <unistd.h>
>#else
>#  error "Sorry - POSIX functionality is needed"
>#endif

That should instead be changed to

#if HAVE_UNISTD_H
#  include <unistd.h>
#else
#  include "ppWin32PosixImpl.h" // or so
#endif

But we'll sort that out later (we anyway have to do the proper POSIX
encapsulation)

>-In ppf_GlobalData, this line was causing a compile error:
>
>	if (Umount (FSURLs [i], ppfMF_force) == 0)
>
>It was corrected to:
>
>	if (Umount (*(FSURLs [i]), ppfMF_force) == 0)
>
>This type of error was corrected several places in ppf_GlobalData.

I couldn't compile much of the code, so it's likely that you encounter many
more such errors.

>-Changed the type of FSURLs in TGlobalData from an array of const pointers
>to URLInfo's, to an array of non-const ones. The reason for this was that
>non-const methods was called on URLInfo's pointed to by elements of FSURLs,
>and this was generating errors.

Where were these called?

>-In TGlobalData, commented out the implementation of SetCWD(). The reason
>was that it was using getcwd (3), which is Win32 incompatible. We'll have to
>get back on this.

Ok.

>-In TGlobalData, I removed this line:
>
>	ppAssert (ppf_IsPlainfsURL (Path));
>
>The reason is that there is no such thing as a ppf_IsPlainfsURL().

Ok. There's also no equivalent for that in the new system.

>-Commneted out implementation of ppf_StatPlain(), because it deleted the
>name parameter of a DirEntry and replaced it. DirEntry can only give a const
>pointer to its name, and the name cannot be set... I'm not exactly sure what
>the point of replacing the name is, so I thought I'd leave it to you to fix
>the problem (are there two versions of DirEntry? One internal, one
>external?, if there is, than that needs fixing). The same goes for
>ppf_LStatPlain().

Yup, that's a known bug. Just leave it for now.

>-After some fooling around, I completely commented out the file
>ppf_OpenDir.cpp . The reason for this is that it didn't compile, I'm not
>exactly sure what each function is supposed to do, and it seems that there
>are two versions of DirEntry: ppf_DirEntry and ppfDirEntry. I don't know
>what to do about that (it doesn't work with removing the ppf and ppf_

See the coment at the top of this mail.

>prefixes, obviously). You'll have to fix this.

Yup, I'll do.

>-I let ppf_PakFileConstants keep its ppf_ prefix. The class should be
>removed anyway, and the constant values placed directly in the
>::pp::internal namespace. I moved initializations to the implementation
>file, as VC++ 5.0 cannot handle initialization of members directly in the
>class declaration.

Ok. Leave it like that for now. The other stuff is more important.

>-commneted out the implementation for PakFile::Mount(), as it didn't use
>URLInfo, and I wasn't sure how to make it do that with the functionality it
>required (namely to get the bare filename with no extension).

<looking>
Ahh, yes. I'll take care of it.

>-commneted out part of the implementation for PakFile::Unmount(). The part
>commented out was the part having to do with the old serialization scheme.
>It'll need to get reimplemented when the new one is in place.

Yup.

>-Part of the implementation for ppf_PakMWriteLEInt64() was commented out,
>since it had constants ending in "LL" (ie, long long). VC++ does not support
>this.

Has to be rewritten anyway (see my comments on compiler specifics in
another mail).

>-The implementation of ppfCloseDir() was commented out. The reason for this
>was that it was deleting const pointers, and this was causing PFile not to
>compile.

Ok, I'll have to look into that anyway.

>-Removed all #warning precompiler directives. MS VC++ 5.0 does not support
>these.

A pity. But ok.


Can you send me your sources so that I can start working on the above items?


	Christian
-- 

Drive A: not responding...Formatting C: instead