Go to bottom

Need help with 1K and crinkler

category: code [glöplog]
I assemble source by Masm32:

\masm32\bin\ml /c /coff %1.asm
\masm32\bin\Link /SUBSYSTEM:WINDOWS /OPT:NOREF %1.obj

commandline for crinkler is:
Code: crinkler drw.obj kernel32.lib user32.lib gdi32.lib opengl32.lib glu32.lib /SUBSYSTEM:WINDOWS /ENTRY:start /UNSAFEIMPORT /HASHSIZE:200 /HASHTRIES:50 /ORDERTRIES:6000 /TRUNCATEFLOATS:8

I see a message:
: warning LNK: Entry point hunk has alignment greater than 1, forcing alignment
of 1

So, after I run out.exe I see no window and app hangs.

Need help.
added on the 2015-04-14 06:30:30 by g0blinish g0blinish
does your application run as expected when you link without crinkler?
if yes, probable causes are:

- your data for alignment requirements (4/16 byte boundaries).add padding bytes or alignment keywords if needed

- you have some fragmented data layout where you rely on the actual sequence of data blocks in the code. beware they might get shuffled by crinkler.

- you have a buffer overflow/access violation (writing/reading more data than defined)

- you specify data in float format and interpret them as integers at some point so the truncatefloats:8 will modify the values you expect

stuff like that is normally the issue for crashes after crinkler compression.
added on the 2015-04-14 08:05:02 by gopher gopher
yes, application runs. seems there are no access violatin - no error messages, I see process in taskmanger list.
added on the 2015-04-14 08:16:43 by g0blinish g0blinish
Does it work without /TRUNCATEFLOATS ?
Does it work with the normal linker if you specify /ENTRY:start ?
added on the 2015-04-14 12:00:58 by Blueberry Blueberry
entry name is Correct. Seems everybody works with crinkler fine:
added on the 2015-04-14 13:42:07 by g0blinish g0blinish
try removing all special crinkler options after /ENTRY:start in your post above.

if it still doesnt run, comment out code in your main loop and see if you get it running just opening a window and having an empty main loop.
added on the 2015-04-14 14:23:27 by gopher gopher
what about alignment message?
added on the 2015-04-14 15:07:48 by g0blinish g0blinish
entry name is Correct.

Sure. The issue is whether your code depends on something in the standard MSVC startup code. You can try that out by specifying /ENTRY:start to the non-Crinkler linker, which will cause it to skip the startup code. If that fails to run, you have some dependency on the startup code.
added on the 2015-04-15 12:48:33 by Blueberry Blueberry
He is using masm, there shouldn't be any default startup code anyways.

goblinish: Attach a debugger?

As already suggested - remove some of the "dirty" crinkler trick options.
First candidates for removal:
/UNSAFEIMPORT - maybe you have some importer problems and do not see them.

If you would provide code etc. it would be way more simple to figure out what the problem is.
added on the 2015-04-15 13:32:18 by las las
Does Crinkler use delta-coding?
added on the 2015-04-15 15:19:29 by rudi rudi
@las, OllyDbg doesn't recognize PE format, I don't know which debugger is proper and what API call to catch.

I remove theese parameters from command line, problem still stays.

probably Crinkler tuned to MSVC, he doesn't recognize alter obj( TinyC or Tasm).
added on the 2015-04-15 16:11:06 by g0blinish g0blinish
Visual Studio has a great debugger. And the VS2013 Community Edition is free, too!
Never had problems with Olly and Crinkler binaries... you just need to be careful to "skip" the decompresser stage properly.
added on the 2015-04-15 16:47:50 by las las
Visual Studio isn't option. Wonder why these issue occurs with Masm32.
added on the 2015-04-15 18:36:32 by g0blinish g0blinish
Maybe check the report.html to see if there's something weird going on, if it tries to rearrange blocks that you expect to be linearly behind eacother.
added on the 2015-04-15 20:06:22 by Harekiet Harekiet
For someone asking for help your feedback to possible solutions is close to 0 :)

Why dont you just provide the first lines of your asm code here until the main loop so we can stop guessing what (most likely you) actually did wrong?

Your secret stuff is probably in a pixelshader anyway as usual so just leave that out.
But tiny win32 init code and mainloop in asm is not exactly rocket science.
added on the 2015-04-15 22:39:32 by gopher gopher
whats drv.obj?
anyway, try linking without all necessary libraries and see if the problem resolves? try remove "/UNSAFEIMPORT" flag. one idea is to vertically find out where the problem is first.
added on the 2015-04-16 00:36:27 by rudi rudi
@gopher, why to spoil prod? As I said intro works stable.
@rudi: srw.obj produced by mmasm32 from the source drw.asm.
added on the 2015-04-16 04:28:21 by g0blinish g0blinish
@gopher, why to spoil prod? As I said intro works stable.

I fail to see how showing window code spoils your prod if all the important stuff thats actually important to the intro is hidden.
added on the 2015-04-16 06:05:22 by mudlord mudlord
anyway, my e-mail available in prods, If somebody want to help - just e-mail, I'll sent source.

Wonder, what's wrong with masm32.
added on the 2015-04-16 06:46:28 by g0blinish g0blinish
Maybe simply try with good ole 1kpack by Hitchhikr
I think it worked under Win7 last time i tried, so it should be 64-bit-ready, as my OS is Win7 for the last 5 years...
win7-64bit that is...
new crinkler-1k-options seem to be on-par with it, but this was some sort of a reminder there still being options if you run out of time, deadline, etc.! ;)

1kpack, 2009-comment, gopher/AlcaTraZ (maker of 4klang together with pOWL/AlcaTraZ):
saved my day at evoke. great stuff and beats crinkler in my case by almost 100 bytes :)

crinkler, 2015-comment, blueberry/Loonies (maker of Crinkler together with mentor/TBC):
- New header and import code specialized for 1k intros, based on the 1k packer used in several TBC and Loonies 1k intros, but improved and generalized. Typically wins more than 100 bytes on a 1k compared to usual Crinkler compression.


Go to top