Nash's SVN builds - DISCONTINUED.

[Rachael]

I have committed a new revision which uses LoadLibrary and GetProcAddress to access the PathRemoveFIleSpecA function, after reading that this *might* resolve the issue on a Novell webpage. If you could try recompiling it now (do a completely fresh build to avoid any linker issues), and let me know if this has an effect, I'd appreciate it.

This is due to what could be considered a fatal design flaw in IE7 which causes shlwapi to have a dependency on the Vista-only delayed loading manager. People have been complaining about this on MSDN vehemently and MS in typical fashion refuses to respond.

It's still linking to that DLL file. I can't diagnose it at the moment, but can look into it when I get home from work.

[Kinsie]

So... where's the new SVN builds site?

[MasterOFDeath]

So... where's the new SVN builds site?

http://svn.drdteam.org/

[Graf Zahl]

... PathRemoveFIleSpecA ...

Why do you even use this function? Does it offer anything that a home made version doesn't (except for being non-portable?) This is precisely the stuff I would never use an OS supplied function for.

[Enjay]

So... where's the new SVN builds site?

Also linked from the Wiki front page, as Nash's builds are.

[edit] Correction, as Nash's builds were. I see that someone has already removed the link. BTW, I'm just building GZdoom r176 and Zdoom r1222. However, both look as if they will report themselves as 1 version older because the only change between 175 and 176 and 1221 and 1222 seems to be a minor edit to the pk3. [/edit]

[Graf Zahl]

GZDoom r176 is the same as r175. The changes were outside the trunk.

[Enjay]

That explains it. I've just compiled, cleaned, recompiled, redownloaded and recompiled to make sure that it wasn't a problem at my end.

[Enjay]

I see that you've just updated Zdoom to r1223. Should I hold off uploading Gzdoom r176 or will you not be making the change to GZdoom soon?

[Graf Zahl]

Don't bother with r176. r177 has just been committed.

[Enjay]

And here I am uploading r176 as we speak. And I thought Tormentor was Mr Impatience. I'll cancel it. Thanks.

[Quasar]

... PathRemoveFIleSpecA ...

Why do you even use this function? Does it offer anything that a home made version doesn't (except for being non-portable?) This is precisely the stuff I would never use an OS supplied function for.

Actually I'm not sure why I was so set on using it. It was used that way in the example code I found for retrieving the full path of an executable, and that's why it was there in the first place. I have now replaced it with a call to my own generic M_GetFilePath routine, avoiding the silly mess with LoadLibrary. Keep in mind however that the code in question here is in a Win32-only module, so portability was *not* one of the concerns. It already has to call GetModuleFileName, which is not avoidable AFAIK. WinXP and later strip the path off the executable name in argv[0].