The current source is not windows-ready yet. I know this because I've tried to compile publisher under Windows98 with Visual C++ 6.0, and there are many libraries missing (some I managed to scrounge up on the net and compile myself) but many aren't included and I can't for the life of me find them online. Hopefully this will be remedied.
Well i opened publisher.dsw and now I'm getting farther....still compiling issues but it's getting there...
lemme know if you manage to compile it. I have no clue about compiling... I'd apreciate it if you'd post a link to it here or at elysiun...me and the other non-programming blenderheads need your help badly!!! maybe even post it under the download section on this site?
I am very, very close now.
Just some unresolved externals, (16) most because I need to compile openssl to get a lib for it, for the encrypt and decrypt stuff.
Having trouble getting openssl to compile right now, though.
I thought I was close too, but I wasn't...I got openssl going but the farther I go the problems keep getting worse and worse.
One thing I couldn't find ANYWHERE was the blendkey.h or something like that, not in the source, nowhere on the net :\
I have a feeling that this snapshot of the source isn't quite ready for windows compilation.
Blenkey.h was the proprietary code for the publisher key, and it is not included for a reason. I think you are supposed to set up a dummy blenkey.h and it shouldn't bug you about it...
Not that I know anything.
is there any chance of getting this monster to compile under the GCC running on windows? (ie, dev-c++/mingw32 or djgpp)?? not all of us have M$VC6 and surely there should be some way to support GCC of all things!!
I think that best result can be done the same Complier that the NaN is using... when the Blender source's are ready... but now it's all waitin' and it's drive people crazy...
I'm working right now on compiling the source with gcc under windows. I've gotten past all the usual problems, (guardedalloc, other includes) and I'm stuck right now on the ghostwinlay.o (compiler seems to not come back from the build) but I should have it worked out by tonight, and I'll be posting it on my site for anyone interested.
dunno, it just makes sense to use GCC, seeing as the original makefiles appear to be written for unix systems. i'm intending to try to compile it under a slightly older version of cygwin b/c that will probably have the most unix-like environment for the build files. plus it already includes a lot of useful libs, like openssl for example, as part of the distribution. if it compiles on cygwin, it'll be a hop skip and a jump to getting it to build on mingw...
There's a bit of a problem in building for windows with the current version of fmod. fmod's new functions take a cd drive argument for dealing with CDs. Is a revamp in order for the blender code, or should I just use an older version of fmod?
Yes, I ran into that extra argument in fmod too. For now I just hardcoded it to "d", but obviously this wouldn't be a long term solution.
This would be something to add on to blender methinks...or perhaps use an older fmod, too.
I looked into it a little bit, and quite frankly, I don't think its appropriate at all to have fmod in blender at all. Their licensing system DEFINITELY doesn't go with gnu.
It's ok, I fixed it.
Fmod docs say that if you pass 0 (NULL) as the first parameter it will just use the default CD drive.
Regarding the licensing, this almost looks the same as the license for the SOLID collision library that they ripped out. Why did they have to remove it then? Prolly 'cause they paid for it already
I guess we have nothing to worry about as long as we don't sell stuff right away.