Page 7 of 7
Re: Nash's SVN builds - an alternative custom build source
Posted: Sat Sep 13, 2008 9:56 pm
by Rachael
Quasar wrote: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.
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sat Sep 13, 2008 10:10 pm
by Kinsie
So... where's the new SVN builds site?
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sat Sep 13, 2008 11:26 pm
by MasterOFDeath
Kinsie wrote:So... where's the new SVN builds site?
http://svn.drdteam.org/
Re: Nash's SVN builds - an alternative custom build source
Posted: Sun Sep 14, 2008 12:41 am
by Graf Zahl
Quasar wrote:... 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.
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sun Sep 14, 2008 4:25 am
by Enjay
Kinsie wrote: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]
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sun Sep 14, 2008 4:32 am
by Graf Zahl
GZDoom r176 is the same as r175. The changes were outside the trunk.
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sun Sep 14, 2008 4:35 am
by 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.
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sun Sep 14, 2008 4:41 am
by 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?
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sun Sep 14, 2008 4:50 am
by Graf Zahl
Don't bother with r176. r177 has just been committed.
Re: Nash's SVN builds - DISCONTINUED.
Posted: Sun Sep 14, 2008 4:56 am
by Enjay
And here I am uploading r176 as we speak. And I thought Tormentor was Mr Impatience.
I'll cancel it. Thanks.
Re: Nash's SVN builds - an alternative custom build source
Posted: Mon Sep 15, 2008 9:19 am
by Quasar
Graf Zahl wrote:Quasar wrote:... 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].