This is a patch allows compile mix with MSVC and
run it as Service (daemon) on Windows NT/2K
patch for Windows
Logged In: YES
I'm hesitant to put this into the main Mixmaster
distribution. I'm considering either placing it in its own
directory in the tarball with instructions on patching for
use with MSVC, or spinning out a canned MSVC
(I don't have the ability to thoroughly test and verify this
For now, I'll point people to your site to get this patch,
though, if they want to use Mixmaster on Windows.
Logged In: YES
mixmasters code already have some files and functions
that are used only on windows. and they contains bugs (for
example in opendir() and readdir() functions).
I don't think that it is good to have separete windows
All windows code are inside #ifdefs so there should not
be any problems un unix.
You've made a few changes that aren't #ifdef'd -- are
these changes directly related to the Windows Service
Also, what's the license requirements for serivice.c?
Can we legally include this code?
> You've made a few changes that aren't #ifdef'd
Only changes that aren't in #ifdefs is in pgpcreat.c.
assert (pgp_getpacket(msg, d) == PGP_PUBKEY);
does exactly the same as
type1 = pgp_getpacket(msg, d);
assert (type1 == PGP_PUBKEY);
So I did not feel the need to use #ifdef.
It can also be written as
type1 = pgp_getpacket(msg, d) == PGP_PUBKEY;
If you like it better... maybe even it is better.
The problem was that assert in windows (MSVC)
is defined as:
#define assert(exp) ((void)0)
void __cdecl _assert(void *, void *, unsigned);
So when compiling release (with NDEBUG defined)
assert's parameter is ignored and because parameter
contains call to pgp_getpacket(msg, d),
pgp_getpacket is not called and d does not get value,
but d is used later in buf_appendi(msg, d->length);.
Another reason not to use #ifdef here is possibility that
there may be some other compilers that defines assert()
the same way
Other changes that are not #ifdef'd are related to DIRSEP
(directory separator). but DIRSEP itself is in #ifdef:
#define snprintf _snprintf
#define DIRSEP '\\'
#define DIRSEPSTR "\\&quot;
#define DIRSEP '/'
#define DIRSEPSTR "/"
> are these changes directly related to the Windows Service
no, all Windows Service code is inside #ifdef WIN32SERVICE
(except service.c and service.h)
> Also, what's the license requirements for serivice.c?
> Can we legally include this code?
This my be a problem... This code is from MSVC sample. It is
ok to use this code if you have (licensed) MSVC. But I don't
know if it is ok to use it with different compiler (Borland,
for example) and distribute it.
Maybe I should write my own service.c....
So for now I think it's ok to apply other changes but
service.c/h and ones in #ifdef WIN32SERVICE.
Changes are in CVS, with the exception of service.c and
Are you planning on writing replacements for those two