> But 4996 is "deprecated" according to my version of MSDN? Why is that
> called "unsecure" now?
4996 is still "deprecated". MSDN says: "Some CRT functions have been
To disable the deprecation warnings, define _CRT_INSECURE_NO_DEPRECATE.
For more information, see Security-Enhanced Versions of CRT Functions."
Using this define didn't make the warnings go away, though.
> > * finally, I got BDB, SVN libraries and most other
> > libraries to compile "o.k." or even "fine"
> What's the difference between "o.k." and "fine"?
Projects compiling "fine" don't require further tweaks nor issue ominous
Other projects required a more "rustic" approach like disabling
manifests. As long
as I don't think these tweaks to be critical, I will call it "o.k.".
> I just checked the openssl docs, and according to them it _should_
> compile just fine. But you might have to adjust the config files (I
> don't think that ./configure will run on Windows).
I will try harder ;)
> Does that mean it doesn't link because of missing modules? I mean you
> just said that openssl doesn't compile yet.
E.g. libapr does create a .lib file but the .dll (?!) complains about a
function. In general, I am completely new to Win64. Perhaps, it will
take some time
to get used to consider linking against kernel32.lib, user32.lib etc.
the right thing
to do for a *64* bit application ..
> > Because I had no time yet to set up a WinXP64 box,
> > I have no idea whether the code actually works.
> At least, it does on WinXP32.
That's good news -- we can use the same code base without zillions of
However, I have no idea of how to maintain a 64 bit variant of TSVN because
building from source requires some human intervention. But that situation
will improve, hopefully.
> > @steveKing: Does it make sense to provide it
> > somewhere in the download section? Just in case,
> > someone wants to give it a spin ..
> You mean just the dll? I don't think that would help much without an
> installer which also sets all the requred registry keys.
> About the openssl and the other libs: I don't think it's necessary to
> compile TortoiseProc with 64-bit support. The dll should be enough
> because AFAIK Win64 can run 32-bit apps just fine?
My thoughts are were the same: provide the 64 bits dll as a replacement
of an already installed 32 bits variant. Since it is highly experimental at
this point of time, this kind of "hands-on" installation should be
> Maybe we should contact Brian C. Barnes (firstname.lastname@example.org) and ask
> him if he's willing to try a testrun? I mean he's the one who first
> asked for 64-bit Windows support.
Good idea. If you don't mind, I will send him the .dll plus installation
instructions and cc you on Monday evening.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Oct 3 16:51:10 2004