Not clearing the direction flag in a certain situation

[Vozzie]

Hy,

While i was trying to make a procedure as small as possible i wonder if what i do is 'safe' in this situation.

It's a masm32 console application with no procedures, just starting from the entrypoint. (The intention was as small as possible...)

I removed a CLD instruction while using lodsb, loopz. But while this application is running it only uses 2 API calls (putchar/getchar). After testing the direction flag has always the right state.

Can I assume that a console application always starts with the direction flag cleared? And if there is no API call used changing them, can there be a situation that the direction flag is changed (by the kernel or something)?

Code Select Expand

skiploopstart:
Mov Ecx, 1
; Cld ; after testing it looks like ok
;     ; not be clearing the direction flag, saves 1 octet
skiploop:
Lodsb
Cmp Al, '['
Jne @F
Inc Cx
@@:
Cmp Al, ']'
Jne skiploop
Loopz skiploop
Jmp process

Another question i have is, is it possible to set up a 'stack frame' that's initial zero? I wrote something like this now...

Code Select Expand

; ; Set up a 'stack frame' to use for memory
; ; Clear memory to zeroes
Mov Edi, Esp
Sub Edi, SMALLAPP_MEMORYSIZE
@@:
Sub Esp, 4
Mov DWord Ptr [Esp], 0
Cmp Esp, Edi
Jne @B


Thanks in advance...

[hutch--]

You are brave if you trust anyone to leave the direction flag in a predictable manner, set it to what you need then reset it back to clear when you are finished.

[Tedd]

The flags are 'yours' - there is a version for your process and no other process can change them (aside from debugging.)
It wouldn't make sense for the any of the flags to randomly change state at some unknown time, otherwise their values would be useless.

When your process starts, the direction flag will be cleared - this is part of the ABI. If you're really paranoid, you can simply clear it once at the start of your program.
It will remain clear until you explicitly change its value (as long as you don't call any other functions that do.)
All API functions that use the direction flag (not too many, I assume) should return with it clear. Although it's entirely possible there are exceptions to this, as always.

Short version: it's safe to assume the direction flag is clear, unless you set it yourself or call a function that does (and not many do.)

[Vozzie]

Thanks all,

It takes a brave man to save one octet. I would not care if it were not to make something as small as possible... I came from +250 bytes and trimmed it down to 126 (127 with cld)...

Trimming down code is not bad, it made me throw away structure, readability, speed and other things you are supposed to take care about... It made me learn some new instructions too...

It compares values multiple times even the condition was met, it uses esi edi ebx but does not preserve them, it ends calling exitprocess with a unbalanced stack,... but it does what it has to do and is small...

So the result is not good, not fast, not beautifull but it is small and does what it should... (the goal was small... fast could've been another intention,...)

Greetings

[Tedd]

And after all that hard work... the code section is rounded up to the PE section size, and still requires a few pages of memory to execute :shock:

[Vozzie]

Lol, true!

Even linking with /ALIGN:16 seems to fail under Win7. I link with a 160k stack from what i use 64k for memory. Not using the stack but initialized data for memory makes the PE large but code smaller...

I came onto the tinype competition and found a tinype_win7 too... (nasm and yasm)... But happy i've spent my time in EasyCode with masm to write it...

http://www.phreedom.org/research/tinype/
http://code.google.com/p/corkami/source/browse/trunk/asm/PE/tinyW7.asm?r=792
http://code.google.com/p/corkami/wiki/PE

The intention has nothing to do with malware btw,... it's a BF commandline interpreter...

Greetings

Update:
After some more reading i came to this document.
http://code.google.com/p/corkami/wiki/InitialValues
Looking to flags everywhere i see that the DF flag is clear.

[dedndave]

there are a number of API functions that do everything from act strangely to hang if the DF is set

[Tedd]

Because they assume it was clear, as per the ABI.

If they set it themselves, then they should clear it before returning.
Thus, everyone is supposed to assume it's clear.