Author Topic: Tiny 'Touch' 32 bits program in C (3 kb) (Read 21754 times)

Gerome · « **on:** September 29, 2006, 02:58 PM »

Hello,

For people who are aware of having an Unix like 'Touch' program, here are the sources + into the zipped attachement, a BAT to compile the source, the compiled source (a 3Kb one)

Code: C [Select]

// ********************************
// Author : Gerome GUILLEMIN
// Coded in pure C using LCC Win32
// Date : 29 th of September 2006
// ********************************
#include <windows.h>
#include <stdio.h>
 
BOOL SetFileToCurrentTime(HANDLE);
 
int main(int argc, char **argv)
{
        HANDLE lngHandle = NULL;
        char szFileName[MAX_PATH+1];
        if ( argc == 2 ) {
                strcpy( szFileName, argv[1] );
            lngHandle = CreateFile(szFileName, GENERIC_WRITE,
                                        FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);
                if (lngHandle && lngHandle != INVALID_HANDLE_VALUE) {
                        SetFileToCurrentTime( lngHandle );
                        CloseHandle( lngHandle );
                        return 1; // => 1 will be the OK return
                }
        }
return 0; // => 0 will be the KO return
}
 
BOOL SetFileToCurrentTime(HANDLE hFile)
{
  FILETIME ft;
  SYSTEMTIME st;
 
  GetSystemTime(&st);                 // gets current time
  SystemTimeToFileTime(&st, &ft);     // converts to file time format
  return SetFileTime(hFile,           // sets last-write time for file
         (LPFILETIME)NULL, (LPFILETIME)NULL, &ft);
}

f0dder · « **Reply #1 on:** September 29, 2006, 04:50 PM »

You really should return '0' since that's the standard returncode for success...

Gerome · « **Reply #2 on:** September 29, 2006, 06:57 PM »

Hello,

You really should return '0' since that's the standard returncode for success...
-f0dder (September 29, 2006, 04:50 PM)

Now you got the sources, you can do it

Personally I prefer telling 1 that is equal to True when successfull and 0 that is equal to 'False' when failed... It's just another point of view!

f0dder · « **Reply #3 on:** September 29, 2006, 07:50 PM »

Now you got the sources, you can do it
Personally I prefer telling 1 that is equal to True when successfull and 0 that is equal to 'False' when failed... It's just another point of view!
-Gerome (September 29, 2006, 06:57 PM)

Not if you ever have to deal with makefiles or the like.
(emphasis is mine).

Jibz · « **Reply #4 on:** September 30, 2006, 03:48 AM »

The idea in returning 0 on success and a non-zero value in case of failure is of course that if the program succeeds we generally aren't interested in why, whereas with a failure it's nice to know why.

So a program can return 1 for running out of memory, 2 for pointer error, 3 for .. etc. That way you can check if there is an error by looking at if the value is zero or non-zero, and if you need to know more about what caused the error you can look at the actual value returned

.

The C standard defines two macros, EXIT_SUCCESS and EXIT_FAILURE, which can be used as appropriate return values to the operating system. They are respectively 0 and 1.

Gerome · « **Reply #5 on:** September 30, 2006, 10:04 AM »

Hi,

...
The C standard defines two macros, EXIT_SUCCESS and EXIT_FAILURE, which can be used as appropriate return values to the operating system. They are respectively 0 and 1.
-Jibz (September 30, 2006, 03:48 AM)

I don't sometimes care of what can say the standards...
Why ?
It's simply psychologic and it has a real explanation :
The common 'human' sense would recognize that a 'TRUE' value seems positive, and 'FALSE' the opposite.
So what ?
I've told to my program to execute this_task and it replied to me that there were NO errors singnaled, so the return is TRUE, else in case of failure it would return 0...
And this common human readable/understandable sense can be also found onto 80% of the APIs here and there, where 0 indicates a failure or a NULL return ( example : Findwindow, SleepEx, ... )

Jibz · « **Reply #6 on:** October 01, 2006, 04:17 AM »

The problem with not following the generally accepted standards and conventions is that your program will behave unexpectedly.

If somebody uses your program in a script or makefile they will automatically assume that the return value will be zero on success, so they will be scratching their heads for a while wondering why your program keeps failing until they look at the source and see it.

Gerome · « **Reply #7 on:** October 01, 2006, 06:00 AM »

Hello,

The problem with not following the generally accepted standards and conventions is that your program will behave unexpectedly.
-Jibz (October 01, 2006, 04:17 AM)

At first, it seems you did NOT read explanations i gave into my previous post.

If somebody uses your program in a script or makefile they will automatically assume that the return value will be zero on success, so they will be scratching their heads for a while wondering why your program keeps failing until they look at the source and see it.

Secondly I gave souces also, and if you don't agree with that, feel free to make your own executable.
At last, there is no way my code lead into crash or alike, the only two return code are 1 in case of success and 0 in case of failure (generally encountered into API calls)
So WTF ?

Jibz · « **Reply #8 on:** October 01, 2006, 06:40 AM »

I am just trying to help and explain, no reason to get angry

.

Gerome · « **Reply #9 on:** October 01, 2006, 06:48 AM »

Hello,

I am just trying to help and explain, no reason to get angry .
-Jibz (October 01, 2006, 06:40 AM)

Please i don't need help onto that part.
FYI, i'm a professional system C/C++, ASM, .NET, PLSQL developper, and i love APIs

Jibz · « **Reply #10 on:** October 01, 2006, 07:29 AM »

And you don't like following standards?

Gerome · « **Reply #11 on:** October 01, 2006, 07:35 AM »

And you don't like following standards?
-Jibz (October 01, 2006, 07:29 AM)

You definately NOT have read my previous posts, you're incredibly blind!

Jibz · « **Reply #12 on:** October 01, 2006, 07:41 AM »

I don't sometimes care of what can say the standards...
-Gerome

If I misunderstood that somehow, please enlighten me

.

Gerome · « **Reply #13 on:** October 01, 2006, 07:44 AM »

I don't sometimes care of what can say the standards...
-Gerome

If I misunderstood that somehow, please enlighten me .
-Jibz (October 01, 2006, 07:41 AM)

Just open you eyes and your mind and all will be then clearer.

mouser · « **Reply #14 on:** October 01, 2006, 07:52 AM »

gerome please try to be more reasonable!

actually Jibz' explanation was a great one I thought (regarding why anything but 0 is used to represent different error codes).

but regardless, this is just one of those cases where it's silly to go against the standard. return codes can actually be used by other programs and i don't see a good reason not to follow convention. just follow in the good hacker tradition and write a curse-filled paragraph in the readme about how you disagree with the standard, and then implement the standard

Gerome · « **Reply #15 on:** October 01, 2006, 07:56 AM »

Hello mouser

gerome please try to be more reasonable!

actually Jibz' explanation was a great one I thought (regarding why anything but 0 is used to represent different error codes).

but regardless, this is just one of those cases where it's silly to go against the standard. return codes can actually be used by other programs and i don't see a good reason not to follow convention. just follow in the good hacker tradition and write a curse-filled paragraph in the readme about how you disagree with the standard, and then implement the standard
-mouser (October 01, 2006, 07:52 AM)

WTF 'standard' ?
And when APIs you're using just return 0 as ERROR, how do you consider standard as standard ?
There are several programming schools, several point of view, and mine is optimistic + API sided, where 0 means ERROR and 1 or TRUE means OK, that's all folks.

f0dder · « **Reply #16 on:** October 01, 2006, 09:10 AM »

Yay for people who don't care about standards. Professional? *cough*

Jibz · « **Reply #17 on:** October 01, 2006, 09:21 AM »

WTF 'standard' ?
-Gerome

How about the ANSI/ISO C standard:

If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned.

Stroustrup (my K&R is in danish and I didn't want to post a translation .. it says basically the same thing though):

The int returned by main(), if any, is the program's return value to "the system." If no value is returned, the system will receive a value indicating successful completion. A nonzero value from main() indicates failure.

MSDN:

By convention, a return code of zero means that the program completed successfully.

For most programs it doesn't matter much what value you return, since nobody is ever going to inspect it anyway. But a program like touch is likely to be used in scripts and makefiles, and that's why I feel it's better to have it return the most standard values.

Jibz · « **Reply #18 on:** October 01, 2006, 10:45 AM »

Btw, if I'm not mistaken, CreateFile returns INVALID_HANDLE_VALUE on failure, which is -1 .. so your program returns your success value of 1 even if the file does not exist.

Gerome · « **Reply #19 on:** October 01, 2006, 11:29 AM »

Btw, if I'm not mistaken, CreateFile returns INVALID_HANDLE_VALUE on failure, which is -1 .. so your program returns your success value of 1 even if the file does not exist.
-Jibz (October 01, 2006, 10:45 AM)

Right

So this is a fix :
if (lngHandle && lngHandle != INVALID_HANDLE_VALUE)

hwtan · « **Reply #20 on:** October 01, 2006, 01:36 PM »

If you want it smaller, here's the program in assembly. Executable file has size of 1536 bytes.

Code: ASM [Select]

.486                                ; create 32 bit code
    .model flat, stdcall                ; 32 bit memory model
    option casemap :none                ; case sensitive
  
    include \masm32\include\windows.inc
    include \masm32\include\kernel32.inc
    include \masm32\include\user32.inc
    include \masm32\include\shell32.inc 
 
    includelib \masm32\lib\kernel32.lib
    includelib \masm32\lib\shell32.lib
 
    .code
start:
 
main proc
        local   commandLine:LPSTR
        local   numOfArgs:DWORD
        local   argsP:DWORD
        local   fileH:HANDLE
        local   currentSysTime:SYSTEMTIME
        local   newFileTime:FILETIME
    
        invoke  GetCommandLineW
        mov     commandLine, eax
        invoke  CommandLineToArgvW, commandLine, addr numOfArgs
        mov     argsP, eax
        cmp     numOfArgs, 2
        jl      failure
        mov     eax, argsP
        mov     ebx, [eax + 4]
        invoke  CreateFileW, ebx, FILE_READ_ATTRIBUTES+FILE_WRITE_ATTRIBUTES, FILE_SHARE_READ+FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL
        mov     fileH, eax
        cmp     eax, INVALID_HANDLE_VALUE
        je      failure
        invoke  GetSystemTime, addr currentSysTime
        invoke  SystemTimeToFileTime, addr currentSysTime, addr newFileTime
        invoke  SetFileTime, fileH, NULL, NULL, addr newFileTime
        invoke  ExitProcess, 0
        
failure:         
        invoke  ExitProcess, -1 
main    endp
    
end     start

Gerome · « **Reply #21 on:** October 01, 2006, 01:39 PM »

Hello,

Nicer

BTW, you can also compile it up to 1024 bytes using PellesC, and still in plain C

hwtan · « **Reply #22 on:** October 01, 2006, 02:17 PM »

Interesting... AFAIK, win32 PE header is already 1KB in side...

Gerome · « **Reply #23 on:** October 01, 2006, 02:20 PM »

Hi,

Interesting... AFAIK, win32 PE header is already 1KB in side...

-ethan (October 01, 2006, 02:17 PM)

Yes, but there are also PE compilation options using MSVC++6.0 that allows you to make 512 bytes length 32 bits executables

Below it's impossible, but 512 bytes for MSVC++ 6 is amazing

f0dder · « **Reply #24 on:** October 01, 2006, 02:21 PM »

Just for fun, here's a 1kb C (well, C++) version, that has proper system return code