Weirdass bug (feature?) in kkrunchy
category: code [glöplog]
hai
http://mudlord.emuxhaven/net/sekret/wtf.rar
demo_uncomp.exe is the plain EXE, uncompressed.
For some odd reason, kkrunchy seems to strip out the dialogs. Is there any way to override said strippage of resources? Or is that a "feature"? Or some weirdass bug I found?
thnx
http://mudlord.emuxhaven/net/sekret/wtf.rar
demo_uncomp.exe is the plain EXE, uncompressed.
For some odd reason, kkrunchy seems to strip out the dialogs. Is there any way to override said strippage of resources? Or is that a "feature"? Or some weirdass bug I found?
thnx
proper linky
http://mudlord.emuxhaven.net/sekret/wtf.rar
http://mudlord.emuxhaven.net/sekret/wtf.rar
it's most likely to avoid capturing the config dialog. considering it is kind of pointless to pick a resolution for a video with a predefined resolution.
video? he's talking about kkrunchy, not kkapture. and iirc there was an option to strip resources indeed.
Weird, kkrunchy doesnt seem to have a switch to disable said resource stripping...Or its not documented at least.
saga: you're right! sorry didn't have enough sleep after partying on easter :(
kkrunchy doesn't strip resources. in fact it'll warn when resources are present since i need to leave (at least parts of) the resource directory uncompressed which increases size.
that said, i also stopped working on it 4 years ago since at some point dealing with the whole AV shit got so frustrating that I completely gave up on both kkrunchy and 64ks; at that point it was just this endless source of frustration where I had to deal with AV crap, video drivers crashing because their "is this a known executable?" detection couldn't deal with kkrunchy EXEs, and people writing me hate mail because they found a kkrunchy-packed trojan on their machine and assumed it was my doing.
long story short: i'm done with exe packers. the overall win32 environment is just too hostile towards packed EXEs for me to bother with it. i'll have a look at the exe, but if it's indeed a kkrunchy bug, don't expect me to fix it.
decipher: wtf? have you ever used kkapture? the video resolution isn't predefined, and kkapture supports changing it (and audio formats) on the fly - it'll just start a new .AVI.
that said, i also stopped working on it 4 years ago since at some point dealing with the whole AV shit got so frustrating that I completely gave up on both kkrunchy and 64ks; at that point it was just this endless source of frustration where I had to deal with AV crap, video drivers crashing because their "is this a known executable?" detection couldn't deal with kkrunchy EXEs, and people writing me hate mail because they found a kkrunchy-packed trojan on their machine and assumed it was my doing.
long story short: i'm done with exe packers. the overall win32 environment is just too hostile towards packed EXEs for me to bother with it. i'll have a look at the exe, but if it's indeed a kkrunchy bug, don't expect me to fix it.
decipher: wtf? have you ever used kkapture? the video resolution isn't predefined, and kkapture supports changing it (and audio formats) on the fly - it'll just start a new .AVI.
Quote:
kkrunchy doesn't strip resources. in fact it'll warn when resources are present since i need to leave (at least parts of) the resource directory uncompressed which increases size.
Weird.
Quote:
i'll have a look at the exe, but if it's indeed a kkrunchy bug, don't expect me to fix it.
Damn DDDD:......I will use *shudder* UPX or even some other packer...
Um, wild shot in the dark: wrong image base address causes the resources not to be loaded?
Yeah, good point actually. If you're using VC++ >=2008 (I think) and the VC++ runtime library (baaad! don't do that in 64ks!!), the startup code has the nasty property of hardcoding the imagebase for the original linked executable as hInstance, and then kkrunchy moves that around.
Solutions:
I remember someone else running into this before, and I think I added patching for the C init code in one of the later kkrunchy versions (i.e. from the test directory), but if you're using an older kkrunchy you have to use one of the three methods above.
...did I mention that this whole crap got old after a while? :)
Solutions:
- Don't use the VC++ RTL at all (preferred solution for me!)
- Use one of the hacks to use old MSVCRT.DLL and c0init instead of the newer runtimes (the old startup code didn't have this problem)
- Disregard the hInstance that VC++ passes to your WinMain and use "hInstance = GetModuleHandle(0);" instead.
I remember someone else running into this before, and I think I added patching for the C init code in one of the later kkrunchy versions (i.e. from the test directory), but if you're using an older kkrunchy you have to use one of the three methods above.
...did I mention that this whole crap got old after a while? :)
And it's "hInstance = (HINSTANCE) GetModuleHandle(0);" - yeah I know this looks weird, but that's how the VC++ used to determine its hInstance internally.
Quote:
I remember someone else running into this before
Take a guess why I might be right :P
*Glare* "Oh, it's you".
who uses winmain in their release builds any ways? :)
rasmus, all those intros that require msvcr*, for example.
lamers :)
lamers :)
Quote:
Disregard the hInstance that VC++ passes to your WinMain and use "hInstance = GetModuleHandle(0);" instead.
....and magically all is well now \o/. The pretty resolution/setting dialog now stays :3