Actual status of intros & dll's
category: general [glöplog]
Quote:
I remmember old days computers...
whenever you see this, you will
a) shit bricks
b) skip the post
c) *sigh* and start swearing
d) Start a 4k Amiga intro. :D
rmeht: shitty apps you use then ;)
First post, long time lurker. :)
I did investigate this some 18 months ago. Found that its almost only Breakpoint that explicitly denounces use of msvcrXXX.dll's and .NET runtime stuff in 64k and 4k.
I like to think that BP orgas have them rules to protect the participants and viewer convenience more than it being some kind of farout advantage. Using STL can blow up sizewise and IMHO doesent really help you that much to begin with when it comes to intromaking. And as far as I can tell you cant make use of .NET without depending on yet another and less common runtime; XNA.
Nevertheless, STL is convenient sometimes. I tried, for some good hours, to compile a dead simple program that used std::vector to run without depending on msvcrt90.dll / msvcp90.dll and failed. In theory it should not be necessary but MS implementation seems to need the dlls. Although it could be possible to circumvent somehow.
Someone mentioned VC6. STL works fine there and uses msvcp60.dll which is included in Windows installations. And linking with VC6 lib and use msvcrt.dll works fine (fingers crossed) in VS2008. Although I suppose its only a matter of Visual Studio versions before that doesent work anymore. Naturally you can still do without msvcrt but, then again, its convenient and more failsafe.
I planned but havent gotten around to investigate how common the new runtime libs are these days. Mind that they're maninfested in /WINDOWS/WinSxS/ under XP. Maybe games install them, maybe they come with .NET installer. Anyone knows? Anyone cares?
I did investigate this some 18 months ago. Found that its almost only Breakpoint that explicitly denounces use of msvcrXXX.dll's and .NET runtime stuff in 64k and 4k.
I like to think that BP orgas have them rules to protect the participants and viewer convenience more than it being some kind of farout advantage. Using STL can blow up sizewise and IMHO doesent really help you that much to begin with when it comes to intromaking. And as far as I can tell you cant make use of .NET without depending on yet another and less common runtime; XNA.
Nevertheless, STL is convenient sometimes. I tried, for some good hours, to compile a dead simple program that used std::vector to run without depending on msvcrt90.dll / msvcp90.dll and failed. In theory it should not be necessary but MS implementation seems to need the dlls. Although it could be possible to circumvent somehow.
Someone mentioned VC6. STL works fine there and uses msvcp60.dll which is included in Windows installations. And linking with VC6 lib and use msvcrt.dll works fine (fingers crossed) in VS2008. Although I suppose its only a matter of Visual Studio versions before that doesent work anymore. Naturally you can still do without msvcrt but, then again, its convenient and more failsafe.
I planned but havent gotten around to investigate how common the new runtime libs are these days. Mind that they're maninfested in /WINDOWS/WinSxS/ under XP. Maybe games install them, maybe they come with .NET installer. Anyone knows? Anyone cares?
Quote:
MS implementation seems to need the dlls
right... "MS implementation" is Dinkumware first of all and are you sure it is not in need of the runtime due to operator new? since the default allocator might be using it (that is unless you coded your own allocator).
This aside, STL is certainly a code-bloat unless the compiler is the god of all compilers everywhere.
Yeah i was down the same road few years back, at the point when i was trying to debug the errors in my own allocator i realized i really don't need all the stuff that comes with abstract containers and just written some own simple linkedlist and vector classes. Right now i'm writing simple 96k game and i am using STL heavily, but this time around i don't care about runtime dependency as it is mainly Linux/FBSD prod where libstdc++ is assumed always available.
Quote:
STL is certainly a code-bloat unless the compiler is the god of all compilers everywhere.
then again, programs with a target size <100k are surely not the preferred playground of the STL ;)
Decipher: 'new' was not the problem, I think. Unless my versions of new and/or the msvcrt.dll version of new caused the problem. The link failed on a cryptic pair of operators that I never really figured out what they did. Like snotemate, I decided it was a waste of energy to pursue and KISS:ed the issue.