Index
> Main > stupid qustions time |
| Author |
|
So please excuse the nO0bie questions.
|
JohnFound 02 Jan 2005, 15:58
You are right about WinAPI - it really slow down applications. But we are talking about Windows applications. You simply can't do some things avoid API. On the other hand, there are a lot of functions in Win32 API that can be avoided - string functions for example.
So, my suggestion is: 1. keep using of API functions as less as possible and only from core Windows .dll's - kernel32, user32, gdi32, etc. 2. Use data manipulating routines only for non critical parts. 3. The size IMHO is more important than the speed - the novadays CPUs are fast enough for the most of the applications (if you choose the proper algorithms), but if you write smaller applications, you really can gain from download time, disk access operations (that are slow as always), more memory for other applications, etc. Regards. |
|||
02 Jan 2005, 15:58 |
|
|
Dr.X 02 Jan 2005, 17:21
JohnFound wrote:
So these files supply the fastest and smallest code? Or just the fact that some of the jobs can only be provided by them? JohnFound wrote:
I've not gotten that far yet, but it is now on my list. 
JohnFound wrote:
So you are saying that the smaller size will provide an overall speed increase in the long run as a side effect? That makes sense to me. Thanks for the fast answers JohnFound. It's much apreciated. -Dr.X |
|||
|
02 Jan 2005, 17:21 |
|
|
vid 03 Jan 2005, 21:41
Quote:
Nope, they are slow too, but these are files you just HAVE to use (otherwise you wouldn't be able to make some input or output). Of course not always onlythese 3, if you wan't something special like access internet or so, but usually kernel, user and gdi are enough. Usually even gdi isn't needed, only when working with graphics combined with windoze's windows.[/quote] |
|||
|
03 Jan 2005, 21:41 |
|
|
Dr.X 04 Jan 2005, 01:09
Vid! HI! The man who wrote the only tutorial I can understand. Thank You!
Quote:
Yeah, that's what I meant when I asked "some of the jobs can only be provided by them" I'm glad you're still around. I'm studying the tutorial again since I fell into work for a few months without being able to persue personal intrests such as fasm. Maybe I can pester you when I have problems understanding it. 
Thanks for answering. -Dr.X |
|||
|
04 Jan 2005, 01:09 |
|
|
vid 04 Jan 2005, 10:27
Quote: Maybe I can pester you when I have problems understanding it If you can't understand samething of my tutorial after reading few times, then you are really welcomed to write me, because that means something is wrong in tutorial and I have to fix it. |
|||
|
04 Jan 2005, 10:27 |
|
|
Madis731 04 Jan 2005, 21:46
APIs are usually meant to ease the process of writing and also size, because you won't have to rewrite the code every time in your code.
I think it is not quite right to say that it is not possible without API. You can for example copy the whole binary data from krnl,usr,gdi,... to your code (as machine instructions) from an API call that you need so now you are able to manage without windows(not exactly ) and
maybe even hand-optimize the copied code. I remember someone used to discover the BitBlt or some other bitmap-copying APIs in Windows and optimized them and got pretty stunning results. A hint: make an int3 before and after some call to API. Now you can run OllyDbg and copy some ASM code to your source (between ints) and use it inline on even optimize it. |
|||
|
04 Jan 2005, 21:46 |
|
|
vid 04 Jan 2005, 22:32
Quote: You can for example copy the whole binary data from krnl,usr,gdi,... But this code uses ring0 (privileged) routines (APIS) which you just can't replace by your ring3 (unprivileged) code. |
|||
|
04 Jan 2005, 22:32 |
|
|
Dr.X 04 Jan 2005, 22:47
Quote:
It's more likely to be the numerous rocks in my head.
-Dr.X |
|||
|
04 Jan 2005, 22:47 |
|
|
Madis731 05 Jan 2005, 10:02
what do you mean - priviledged code. Just copy/paste will do fine because CPU doesn't know it MSR is read within kernel32.dll image or youcode.exe because they are all grey matter in the space of RAM (CPU cache...)
Why C-code is so big??? It holds all necessary calls to the procedures it uses. It doesn't need any extra libraries and this is why it is portable. And you can make yours too - through assembly. Am I missing some real hard evidence - facts - that my statement was completely wrong  |
|||
|
05 Jan 2005, 10:02 |
|
|
vid 05 Jan 2005, 17:19
Quote: Just copy/paste will do fine because CPU doesn't know if MSR is read within kernel32.dll image or youcode.exe because they are all grey matter in the space of RAM (CPU cache...) Yes, it will work, i was saying that you can't overload ALL libraries with this approach (like in DOS), because some of them needs to be runned in PROTECTED MODE, which is thing that causes that sometimes grey matter can use MSR (which is lower word of CR0 since 386), and sometimes it can't, depending on rights set for process. |
|||
|
05 Jan 2005, 17:19 |
|
|
MCD 05 Jan 2005, 19:52
JohnFound wrote:
Quote:
I only agree partly with you, JohnFound. I think that especially most commercial software should become smaller (They are most all too much overloaded with whatnots and bad RAD programming style), but this doesn't mostly depends on code size, but rather on data(files) sizes   , since their codes usually make up only a small part of the entire software paket.
So, I think, it is really not worth writing small programs. I personally think that speed optimizations are more important, but you are right with Quote: the novadays CPUs are fast enough for the most of the applications (if you choose the proper algorithms) Don't understand me wrong, cause I neither like chunky/sloppy written programs, but sometimes speed anticipates with size. A good example are string instructions compared with general integer instructions(or even MMX/SSE ones). The string versions are usually much smaller and easier to use, but they are even slower than standard integer instructions. For example, copying large amounts of data with "mov" is usually faster than with "rep movsd". (Tested on a Pentium II,III and an AMD Athlon XP+ CPU via RDTSC instruction, 10% to 50% slower). This certainly don't disturb much programs like Flat Assembler (which uses lots of string operations), but it will certainly slow down CPU/memory intensive programs. Another good example is the "loop" instruction, which was up to 5 times slower than a similar code build by "jnz" and "dec" instructions. _________________ MCD - the inevitable return of the Mad Computer Doggy -||__/ .|+-~ .|| || |
|||
|
05 Jan 2005, 19:52 |
|
< Last Thread | Next Thread > |
Forum Rules:
|