flat assembler
Message board for the users of flat assembler.

Index > High Level Languages > C++ or ASM

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Vortex: how?
Post 09 Apr 2006, 21:24
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
vid wrote:
Vortex: how?


the easiest way is to just set a custom entry point and skip all the c run-time library and command line parsing code
Code:
#pragma comment( linker, "/ENTRY:_entrance@0" ) 
void _stdcall entrance( void ) {
    return;
}

//or

#pragma comment( linker, "/ENTRY:entrance" ) 
void _cdecl entrance( void ) {
    return;
}
    


there are also tricks like: merging all the sections
Code:
#pragma comment( linker, "/MERGE:.text=.data" )
#pragma comment( linker, "/MERGE:.rdata=.data" )
#pragma comment( linker, "/SECTION:.flat,RWE" ) //new section RWE access
#pragma comment( linker, "/MERGE:.data=.flat" )
    


of course this is for pellesC i'm not sure about MSVS as i do not use it (but it should work as the MSDN has the /MERGE and /ENTRY linker comments documented)

_________________
redghost.ca
Post 09 Apr 2006, 21:40
View user's profile Send private message AIM Address MSN Messenger Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
What GCC are you using? You forgot to strip the result (-s). I'm using DJGPP (GXX 4.01, haven't installed 4.10 yet) and it's only 377k (and only 135k after using UPX, which itself is written in C++). This bloat is atypical of larger programs, so I wouldn't worry about it. However, yes, I would suggest you study other languages before jumping on the C++ bandwagon completely. A little tinkering is okay, but don't put all your eggs in one basket (heh, Happy Easter!). Smile

Plue wrote:
fox wrote:
I think they compile to machine language.. but you are better away from them. Delphi is the OOP version of Pascal, and it was mainly supported by Borland. But Borland has abandonned it..

That's not true. A simple console hello world I made here is 9 216 bytes. I also speed tested Delphi against gcc some time ago, and it produces faster code.

The exes are only big if you use the predefined library of GUI components. This is the same for any language. An hello world compiled with gcc: 509 576 bytes
Code:
#include <cstdlib>
#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
    system("PAUSE");
    return EXIT_SUCCESS;
}    


And I don't think it's abandoned, they just released Delphi 2006.
Post 10 Apr 2006, 22:08
View user's profile Send private message Visit poster's website Reply with quote
Adam Kachwalla



Joined: 01 Apr 2006
Posts: 150
Adam Kachwalla
Why bother with high-level languages? The file ends up being ten thousand times larger than it is supposed to be! Pure assembly language (and pure machine xode) is the best way to go, because you can control all the bytes placed in the file.
Post 03 May 2006, 06:24
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
How on earth can you get that simple C++ sample so large? Without using *ANY* tricks, it compiles and links to ~27kb with vc2003. It goes to ~73kb if I add
Code:
cout << "Hello, world!\n";
    

or ~45kb if I use printf instead.

If I skip the system() call and link with Jibz WCRT library instead of the default CRT, again using no dirty tricks like section merging, the exe is down to 3.072 bytes. And that's with the formatting power of printf...
Post 03 May 2006, 10:59
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
f0dder, I'm sure some of that functionality is in the OS, so the size comparison probably ain't entirely fair. Besides, there are better examples (see below) than this useless snippet we're referring to. Also, I wonder why it links in the whole printf() if the string requires nothing but a puts(). Razz

Here's a better example (since UPX is written in C++):

UPX 2.00 for DOS (DJGPP2/COFF): 647,168 bytes (277,676 packed)
UPX 2.00 for Windows (WIN32/PE): 490,496 bytes (198,144 packed)

EDIT: UPX for DOS supports "upx --best .../*.exe" for recursive dir searching/running, unlike the Win32 version. This should be taken into account when comparing filesizes.

P.S. OpenWatcom 1.6 is released. You can also download individual .ZIPs for a partial install if you don't need everything (help docs, C++, Win32 target files, etc.).


Last edited by rugxulo on 28 Dec 2006, 20:52; edited 1 time in total
Post 04 May 2006, 06:55
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:
f0dder, I'm sure some of that functionality is in the OS, so the size comparison probably ain't entirely fair.

Well, if there's OS support, why not use it? Wink
But yes, iirc Jibz WCRT does use wsprintf - which also means it doesn't support floating point formatters. Jibz is working on that, though, but it's currently only in beta and he's hard pressed for time, real life and all that.

Quote:

Besides, there are better examples (see below) than this useless snippet we're referring to.

Glad to see I'm not the only one thinking that measuring "hello, world" size is useless.

Quote:

Also, I wonder why it links in the whole printf() if the string requires nothing but a puts().

Because I used `printf` and not `puts` ^_^ - on purpose, to show that you can get printf without very much overhead.

Quote:

UPX 2.00 for DOS (DJGPP2/COFF): 647,168 bytes (277,676 packed)
UPX 2.00 for Windows (WIN32/PE): 490,496 bytes (198,144 packed)

For DOS, you need a *lot* of code because there's not much OS support. The Windows version of UPX seems to be compiled with GCC, which isn't exactly known for good&tight code generation (comparing GCC3 to VC7+, that is - GCC4 is appearantly better, but I haven't found a win32 port yet so I haven't played with it myself.)

But sure, UPX would be one of the somewhat large executables for what it does - it uses a bunch of not-so-trivial C++ features, and used those before the C++ community knew how to "do it well". If you look at the UPX source you'll see that it is *not* a very pretty sight Smile

Quote:

P.S. OpenWatcom 1.5 is released (only Win32 and OS/2 install packages, for now).

That's interesting - I haven't used Watcom for several years. How is it's code generation compared to VC7 and later? It used to be good in the DOS days, but last I checked Intel and Microsoft compilers produced quite better results.
Post 04 May 2006, 09:27
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
f0dder wrote:

Because I used `printf` and not `puts` ^_^ - on purpose, to show that you can get printf without very much overhead.


Bah, and they say compilers know everything these days. Razz

Quote:
For DOS, you need a *lot* of code because there's not much OS support.


That's part of its charm. Wink

Quote:
If you look at the UPX source you'll see that it is *not* a very pretty sight Smile


I only looked at a little, but it actually seemed pretty clean and nice, comparatively, to my eyes. Then again, C++ is all Greek to me. Laughing

Quote:
That's interesting - I haven't used Watcom for several years. How is it's code generation compared to VC7 and later? It used to be good in the DOS days, but last I checked Intel and Microsoft compilers produced quite better results.


I don't have VC7 or Intel compilers, so I dunno. Anyways, Open Watcom seems pretty good to me, getting stronger with every new version. There really is no magic compiler: it all depends on what you know, what you intend, and how you use it. OW has been called the potential DJGPP killer (if you can believe that!).

P.S. I know this is the wrong thread, but...UPX has no memory overhead for most formats. So, maybe using it blindly for everything would be bad, but most medium-sized, non-concurrent Win9x programs are okay.
Post 05 May 2006, 04:29
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

I don't have VC7 or Intel compilers, so I dunno.

You can get VC7.1 (2003) from Microsoft for free - the full optimizing version. And the license is pretty liberal, you could even use the compiler to write your own OS. That's pretty interesting, since MS's for-free software downloads usually have very restrictive licenses.

Quote:

OW has been called the potential DJGPP killer (if you can believe that!).

I'm not too fond of DJGPP, although it was my main C++ compilers years back. Has to do with it's file format and the standard library. If I needed to do 32bit dos development these days, I would use Visual C++ and probably the HX dos extender.

Quote:

P.S. I know this is the wrong thread, but...UPX has no memory overhead for most formats.

Perhaps not overhead in the amount of bytes used (ie, "in-place decompression") - but for multitasking protected mode operating systems, it will result in "dirty pages", as mentioned before. Dirty pages are bad.
Post 05 May 2006, 10:46
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Quote:
I'm not too fond of DJGPP, although it was my main C++ compilers years back. Has to do with it's file format and the standard library. If I needed to do 32bit dos development these days, I would use Visual C++ and probably the HX dos extender.


HX is useful in DOS for its Windows emulation. I like it. However, so far I've only bothered to run two programs with it: e3 (Win9x version, vi interface, mainly because the 16-bit DOS version stinks) and the Windows console version of 7-Zip. There are some other good DOS extenders, too (WDOSX, DOS/32A, Causeway, PMODE, etc.).

If you don't like DJGPP, that's fine. It's not perfect (yet, heheheh), but it does have POSIX compatibility, supports LFNs, and is free. I've noticed that lots of my favorite DOS stuff was compiled by it. Plus, all those GNU utils don't hurt either. Smile

BTW, your VC link at http://f0dder.has.it is outdated. I'm not majorly interested in trying it (too huge!), since DJGPP and OpenWatcom are much more interesting to me for my hobbyist needs (for now): Very Happy

Quote:

The Visual C++ Toolkit 2003 has been replaced by Visual C++ 2005 Express Edition. Visual C++ 2005 Express Edition provides a complete integrated development and debugging environment making it the easiest way to create powerful applications using the C/C++ language. Visual C++ 2005 Express Edition also contains an enhanced version of the C/C++ optimizing compiler for the fastest executables. Best of all, the Visual C++ 2005 Express Edition is completely free!
Post 09 May 2006, 13:05
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I used to use WDOSX myself, "back in the days" - but it's not been under development for quite some time. HX seems to be quite decent and still supported.

My main reason for not liking DJGPP is actually the POSIX stuff Smile, it took too much code to support this under DOS, while I really just wanted ANSI and small programs. Using DJGPP today is pointless for me, since I'm not dealing with DOS anymore (and let the lack of protection and multitasking rest in peace!)

Quote:

BTW, your VC link at http://f0dder.has.it is outdated.

Oh crap. So now you can't download the relatively small VC2003 package but have to get the full VC2005 Express...

Well, check this link out: http://www.softpedia.com/get/Programming/Other-Programming-Files/Microsoft-Visual-C-Toolkit.shtml .

EDIT: oh well, at least the express editions won't stop being free: Effective April 19th, 2006, all Visual Studio 2005 Express Editions are free permanently. -- http://msdn.microsoft.com/vstudio/express/support/faq/
Post 10 May 2006, 12:19
View user's profile Send private message Visit poster's website Reply with quote
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
I was thinking about downloading the express edition, since it's now forever free... but it seems it requires winxp sp2, and mine is sp1 Sad
Post 12 May 2006, 19:25
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
OzzY wrote:
I was thinking about downloading the express edition, since it's now forever free... but it seems it requires winxp sp2, and mine is sp1 Sad


Get SP2 then Smile

It might be possible to manually extract the install files and get just the compiler, linker and libraries that way... haven't tried, though.

_________________
Image - carpe noctem
Post 13 May 2006, 10:14
View user's profile Send private message Visit poster's website Reply with quote
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
SP2 is a ruge download and I'm trying to keep my system as light as possible.
Does SP2 installation requires a serial number or something? Because I lost my serial. (Soon, I'm moving to Linux anyway...)
How much time does it take to download and install SP2?

Quote:
It might be possible to manually extract the install files and get just the compiler, linker and libraries that way... haven't tried, though.

What do you mean?
I tried unpacking the internet-installer version (which downloads the files and install) with WinRAR and it extracted!
But, are you talking about extracting the full ISO version?
And how would be the setup of the files? (just unpack?)

Thanks
Post 13 May 2006, 20:38
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
If you're using a pirated XP with the "DevilsOwn" cdkey, then don't install SP2 Smile

How much time it takes to download and install depends on your internet connection. It *is* rather large, close to 270 megabyte for the english version. As for install time, you can either apply SP2 to a currently installed XP, or you can slipstream the service pack and make a bootable windows install CD that includes it (http://www.nliteos.com + http://www.ryanvm.net/msfn/ makes for some very LEAN_AND_MEAN windows installs!).

Quote:

But, are you talking about extracting the full ISO version?
And how would be the setup of the files? (just unpack?)

I was thinking the ISO version, yes... I haven't really looked at it, but I guess MS uses cab files as usual, so it should be possible to locate compiler, linker, libraries, includes in there... if it's .MSI based you'll need different tools, but I think MSI decompilers are available nowadays?
Post 13 May 2006, 20:58
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
f0dder wrote:
I used to use WDOSX myself, "back in the days" - but it's not been under development for quite some time.


Feb. 2005 isn't really that long ago. But, yeah, development has apparently stopped. Sad

Quote:
HX seems to be quite decent and still supported.


Yes, it is. Go Japheth go! Very Happy
Post 14 May 2006, 00:27
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
all a big read for me with such little time.

C is a fast HLL while C++ is a slower more secure HLL. Master them both, then use a disassembler and cut out what isn't used but still included anyway. Then clean "the garbage bytes". And yes, i'd know this would be hard. I'm sure you can do something like the following to find out where your program begins and ends or certain aspects of part of the program where you might wanna use faster or different calculation methods:

Code:
char identA[]="Alright, here i am. This is identA where you shall 
look for me using a hex editor or disassembler. Oh yea, and incase you 
forget what this line is, you can use the following password to find me 
faster: 7da33d"; // note: 7da33d is your favorite password.    


Note: The code won't include the in text newlines. lol
Post 23 Jul 2006, 17:17
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
[quote=kohlrak]
C is a fast HLL while C++ is a slower more secure HLL.
[/quote]
Nonsense Smile

C++ is a multiparadigm language; you can write procedural code, object-oriented code, template metaprogramming code... it's speed depends on the code you write (and the compiler), nothing about C++ makes it automatically slower than C. Nor more secure, really, if you still use libc.

And you can still write high-performance code even if it's object-oriented, you just need to know what you're doing (and use a non-retarded compiler).

[quote=kohlrak]
Master them both, then use a disassembler and cut out what isn't used but still included anyway.
[/quote]
That's silly.

Just write your code properly instead. Use an alternative libc/runtime if the one you have isn't good enough. And if you really feel like doing the silly "cutting", use your compiler switch to generate an assembly listing instead of going through a disassembler.
Post 24 Jul 2006, 10:58
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
C++ is a multiparadigm language; you can write procedural code, object-oriented code, template metaprogramming code... it's speed depends on the code you write (and the compiler), nothing about C++ makes it automatically slower than C.


Correct, but when you learn C++, most of the time thy don't tell you about printf over cout << or any other C equivalents, they just tell you the C++'s standard library (even though it's not part of the C++ language, and is only included with almost every compiler). That's the problem, they teach you the slow stuff... It was only by a random topic i found in another community that told me that the C equivalents were faster and that there even were any.

Quote:
Nor more secure, really, if you still use libc.


I'm not sure how it works, but sometimes in C, you can make calls to functions and not fill all the parameters. It's this assembly too, not all macros or functions have to have their parameters filled. The alert boxes come to mind. That makes C++ a little easier to debug than C or assembly, which shouldn't really matter to the perfect coder, but everyone makes mistakes. Here's a tip for your friends though, make them learn assembly, cause you won't beleive how much un-worth it, it really is.

Quote:
1 What's Wrong With Assembly Language
Assembly language has a pretty bad reputation. The common impression about assembly language programmers today is that they are all hackers or misguided individuals who need enlightenment. Here are the reasons people give for not using assembly:
Assembly is hard to learn.
Assembly is hard to read and understand.
Assembly is hard to debug.
Assembly is hard to maintain.
Assembly is hard to write.
Assembly language programming is time consuming.
Improved compiler technology has eliminated the need for assembly language.
Today, machines are so fast that we no longer need to use assembly.
If you need more speed, you should use a better algorithm rather than switch to assembly language.
Machines have so much memory today, saving space using assembly is not important.
Assembly language is not portable.
These are some strong statements indeed!

Given that this is a book which teaches assembly language programming, written for college level students, written by someone who appears to know what he's talking about, your natural tendency is to believe something if it appears in print. Having just read the above, you're starting to assume that assembly must be pretty bad. And that, dear friend, is eighty percent of what's wrong with assembly language. That is, people develop some very strong misconceptions about assembly language based on what they've heard from friends, instructors, articles, and books. Oh, assembly language is certainly not perfect. It does have many real faults. Those faults, however, are blown completely out of proportion by those unfamiliar with assembly language. The next time someone starts preaching about the evils of assembly language, ask, "how many years of assembly language programming experience do you have?" Of course assembly is hard to understand if you don't know it. It is surprising how many people are willing to speak out against assembly language based only on conversations they've had or articles they've read.

Assembly language users also use high level languages (HLLs); assembly's most outspoken opponents rarely use anything but HLLs. Who would you believe, an expert well versed in both types of programming languages or someone who has never taken the time to learn assembly language and develop an honest opinion of its capabilities?

In a conversation with someone, I would go to great lengths to address each of the above issues. Indeed, in a rough draft of this chapter I spent about ten pages explaining what is wrong with each of the above statements. However, this book is long enough and I felt that very little was gained by going on and on about these points. Nonetheless, a brief rebuttal to each of the above points is in order, if for no other reason than to keep you from thinking there isn't a decent defense for these statements.

Assembly is hard to learn. So is any language you don't already know. Try learning (really learning) APL, Prolog, or Smalltalk sometime. Once you learn Pascal, learning another language like C, BASIC, FORTRAN, Modula-2, or Ada is fairly easy because these languages are quite similar to Pascal. On the other hand, learning a dissimilar language like Prolog is not so simple. Assembly language is also quite different from Pascal. It will be a little harder to learn than one of the other Pascal-like languages. However, learning assembly isn't much more difficult than learning your first programming language.

Assembly is hard to read and understand. It sure is, if you don't know it. Most people who make this statement simply don't know assembly. Of course, it's very easy to write impossible-to-read assembly language programs. It's also quite easy to write impossible-to-read C, Prolog, and APL programs. With experience, you will find assembly as easy to read as other languages.

Assembly is hard to debug. Same argument as above. If you don't have much experience debugging assembly language programs, it's going to be hard to debug them. Remember what it was like finding bugs in your first Pascal (or other HLL) programs? Anytime you learn a new programming language you'll have problems debugging programs in that language until you gain experience.

Assembly is hard to maintain. C programs are hard to maintain. Indeed, programs are hard to maintain period. Inexperienced assembly language programmers tend to write hard to maintain programs. Writing maintainable programs isn't a talent. It's a skill you develop through experience.

Assembly language is hard. This statement actually has a ring of truth to it. For the longest time assembly language programmers wrote their programs completely from scratch, often "re-inventing the wheel." HLL programmers, especially C, Ada, and Modula-2 programmers, have long enjoyed the benefits of a standard library package which solves many common programming problems. Assembly language programmers, on the other hand, have been known to rewrite an integer output routine every time they need one. This book does not take that approach. Instead, it takes advantage of some work done at the University of California, Riverside: the UCR Standard Library for 80x86 Assembly Language Programmers. These subroutines simplify assembly language just as the C standard library aids C programmers. The library source listings are available electronically via Internet and various other communication services as well as on a companion diskette.

Assembly language programming is time consuming. Software engineers estimate that developers spend only about thirty percent of their time coding a solution to a problem. Even if it took twice as much time to write a program in assembly versus some HLL, there would only be a fifteen percent difference in the total project completion time. In fact, good assembly language programmers do not need twice as much time to implement something in assembly language. It is true using a HLL will save some time; however, the savings is insufficient to counter the benefits of using assembly language.

Improved compiler technology has eliminated the need for assembly language. This isn't true and probably never will be true. Optimizing compilers are getting better every day. However, assembly language programmers get better performance by writing their code differently than they would if they were using some HLL. If assembly language programmers wrote their programs in C and then translated them manually into assembly, a good C compiler would produce equivalent, or even better, code. Those who make this claim about compiler technology are comparing their hand-compiled code against that produced by a compiler. Compilers do a much better job of compiling than humans. Then again, you'll never catch an assembly language programmer writing "C code with MOV instructions." After all, that's why you use C compilers.

Today, machines are so fast that we no longer need to use assembly. It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware. There are many raging debates about the speed of machines versus the speed of the software, but one fact remains: users always want more speed. On any given machine, the fastest possible programs will be written in assembly language.

If you need more speed, you should use a better algorithm rather than switch to assembly language. Why can't you use this better algorithm in assembly language? What if you're already using the best algorithm you can find and it's still too slow? This is a totally bogus argument against assembly language. Any algorithm you can implement in a HLL you can implement in assembly. On the other hand, there are many algorithms you can implement in assembly which you cannot implement in a HLL.

Machines have so much memory today, saving space using assembly is not important. If you give someone an inch, they'll take a mile. Nowhere in programming does this saying have more application than in program memory use. For the longest time, programmers were quite happy with 4 Kbytes. Later, machines had 32 or even 64 Kilobytes. The programs filled up memory accordingly. Today, many machines have 32 or 64 megabytes of memory installed and some applications use it all. There are lots of technical reasons why programmers should strive to write shorter programs, though now is not the time to go into that. Let's just say that space is important and programmers should strive to write programs as short as possible regardless of how much main memory they have in their machine.

Assembly language is not portable. This is an undeniable fact. An 80x86 assembly language program written for an IBM PC will not run on an Apple Macintosh. Indeed, assembly language programs written for the Apple Macintosh will not run on an Amiga, even though they share the same 680x0 microprocessor. If you need to run your program on different machines, you'll have to think long and hard about using assembly language. Using C (or some other HLL) is no guarantee that your program will be portable. C programs written for the IBM PC won't compile and run on a Macintosh. And even if they did, most Mac owners wouldn't accept the result.

Portability is probably the biggest complaint people have against assembly language. They refuse to use assembly because it is not portable, and then they turn around and write equally non-portable programs in C.

Yes, there are lots of lies, misconceptions, myths, and half-truths concerning assembly language. Whatever you do, make sure you learn assembly language before forming your own opinions. Speaking out in ignorance may impress others who know less than you do, but it won't impress those who know the truth.


Something i saw from a web page i'm learning Assembly off of. And it's very true that how many people who know C++ or such Curse at assembly. Why? the time consuming thing. I'm not kidding you, a C++ teacher at my school said he saw his friend coding in assembly and he thought it was crazy or insane.
Post 24 Jul 2006, 15:57
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Patrick_



Joined: 11 Mar 2006
Posts: 53
Location: 127.0.0.1
Patrick_
Adam Kachwalla wrote:
Why bother with high-level languages? The file ends up being ten thousand times larger than it is supposed to be! Pure assembly language (and pure machine xode) is the best way to go, because you can control all the bytes placed in the file.


Assembly is great... it's my favorite language, even before C. But in some cases, dealing with APIs in assembly is just a pain in the butt. Therefore, a higher-level language is a bit more practical in that matter. Also, portability is an issue with assembly. For apps I know I don't want to run on Windows, I use assembly (I use Linux only). Otherwise, I'll probably use C, unless the program can run fine in LINE.

When I code in C, I use the following flags, to create a very small executable (nowhere near as small as pure assembly, however):

gcc -Os -s -fomit-frame-pointer -o app app.c;strip app;upx --brute app


Last edited by Patrick_ on 25 Jul 2006, 14:31; edited 1 time in total
Post 24 Jul 2006, 22:12
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.