vs2010 build

[MustardJeep]

Not sure if anyone is interested but crossed a threshold and felt like sharing.

VS2003 had such style I decided as a hobby to start porting the code base up to VS2010.

I've had some success roughly 44 out of the 97 files in the all client project still fail but considering it started at 94 out of 97 I'm feeling happy. I'm keeping the dependencies mostly the stock ones, I've swapped out for a precompiled OpenSSL as nmake was having fits trying to compile some of the crypto directories. aside from that all original factory parts so to speak.

Biggest issue seems to be style changes from 2003 to 2010 with a largish pile of functions needing renamed as their names are now part of the std lib and the functionality of many is no where near the same.

more later.

[Hoikas]

Not sure if you're interested, but another guy called skoader has a lready done this: viewtopic.php?f=92&t=605

Also, the H-uru fork uses cmake to generate VS solutions for any version imaginable. http://git.io/Plasma

This is in the interest in preventing lots of duplicated effort.

[Christian Walther]

MJ, have you by any chance succeeded in building a working CyPython 2.3 with VS 2010? That was my major sticking point, also with Skoader’s code. If I remember correctly, I kept getting strange crashes even after fixing the obvious errors, so I gave up after a while and am now sticking to Python 2.7 (with the H-uru codebase) on VS 2010, and VS 2003 for Python 2.3 and the OU codebase.

[Skoader]

Hi Christian,

My fork compiles with Python 2.3 and VS2010.
Check out the change to pythonrun.c in this commit which fixes a crash with VS2005 and up.

I'm guessing that's your problem.

[MustardJeep]

yeah saw other people had already been there done that when porting up to vs2010 but seriously where's the fun of using someone else's code? This is a hobby that I'm having some serious fun with.......gah that makes me sound like such a nerd.

As for the python... Not so much yet man having some problems with enviromental variables since the oldie moldy dependencys don't register themselves very well on win7. currently down to 32 files left but that includes a heap of "cannot open file" errors. when I get it I'll definany give a shout and tack on my mantis error list. would you belive to get to this point is only seven errors?


P.S. ref() is now officially a four letter word to me. <laughter>

[Christian Walther]

Check out the change to pythonrun.c in this commit which fixes a crash with VS2005 and up.

I'm guessing that's your problem.

No, that one figured under “obvious errors”.

I don’t remember exactly what the problem was. Maybe I’ll have another look when I get around to it.

[Skoader]

Hmm, from memory that's the only change of any real significance I made to 2.3.

MustardJeep,
I hear ya, I'm also having a blast.

[MustardJeep]

Time to pick some brains.........

\plasma20\sources\plasma\nucleuslib\pnnetprotocol\private\Protocols/Srv2Vault/pnNpSrv2Vault.h(155): error C2504: 'SrvMsgHeader' : base class undefined

I've got several files worth of SrvMsgHeader base class being used but no clues to where the class is located.

Anyone know?

P.S. Down to 25/97

[Mac_Fife]

I'm no expert on this, but it sounds to me like you've got SERVER defined somewhere, turning on conditional code that doesn't belong in the client. Some of the CWE code modules are shared with the (unreleased) Cyan server, and I think the missing definition would have come from \plasma20\sources\plasma\ServerLib\psUtils\psUtils.h (see the comment in \Plasma20\Sources\Plasma\NucleusLib\pnNetProtocol\Pch.h around line 45).

[MustardJeep]

huh....well I'll give it a check once I get off work tonight. Wouldn't suprise me to terribly if that's the case all the inheritance, inclusion, lib paths got wiped also. so why not the build type? ah well.