Index
> Windows > Tutorial? |
| Author |
|
|
zxcv 09 Jan 2008, 10:08
Thres no good tutorial for this, at least i didnt found any.
win32 api use only cdecl and stdcall, and can be imported from libraries like: kernel32.dll - basic, functions that access memory, processes, threadas, etc. ws2_32.dll - network. msvcrt.dll - strings and data managment. Functions like strstr, malloc. note that all libs except msvcrt are stdcall (function removes arguments from stack, so if u wana call it twice u have to push them again, stdcall save arguments). Registers ebx, esi, ebp and edi are constant. |
|||
09 Jan 2008, 10:08 |
|
|
Madis731 09 Jan 2008, 10:54
1) The hard way - search the forum for CreateWindowEx
2) Easier way - try my included package of collected interesting stuff Sometimes slow: http://www.tud.ttu.ee/~t060429/Up/Package.7z Array is the easiest to start from (but its without a CreateWindow command). Sometimes the samples are so old that they do not even compile  well
work for the reader. 3) Somewhat easy is to look around Projects section of this forum and download some er... projects. I might suggest: - Calculator - Mandelbrot - Alarm - Digital Clock - Sudoku - Analog Clock and some mine: - Conversion Dialog (message handling, redraw, keyb. input, etc.) - Electro (everupdating package of the schematic drawing/simulating thingy)
|
|||||||||||
|
09 Jan 2008, 10:54 |
|
|
AlexP 10 Jan 2008, 04:48
lol your link of "azillionmonkeys" has a lot of very slow algo's... My Euclidean algo takes only 7 lines of assembly (like three are moves and two are spent on the jcc), his ASCII conversion technique is extremely stupid because u just need to add a constant to each byte!! Sry, but duhh. Some other algo's I found there (actually, a lot), including StrLen functions and others are way too big! Most of them that I looked at I have implemented in under ten lines, the StrLen function is usually in-lined by compilers and is not nearly as long as the one his comp. inserted. Wow, don't use that site
 . |
|||
|
10 Jan 2008, 04:48 |
|
|
bitRAKE 10 Jan 2008, 05:47
Some people will not agree with me, but here is how I started programming in assembler and it worked (but that isn't proof of anything):
1. Get yourself a debugger. I recommend OllyDbg. Just load any program into it, and start changing stuff and writing code. You can do this by double-clicking on a line. The cool part is how there is no gap between writing and executing code - you type something and see how it works right then. If you break something just quit OllyDbg or restart windows - it is really rare that any real damage could be done (backups are a good thing). 2. Read the PSDK - nothing like hearing it from the horses mouth. Yeah, the examples are in C++, but you are going to learn how to read that too. You'll be able to link the source examples on the board here and the PSDK text fairly easy before long. Things will go wrong so get comfortable with OllyDbg/(debugger) and how code looks there verses your source file. Comrade has a patched version of FASMW that puts OllyDbg one keystroke away. This is the fastest way to get jump started, really. Pick some simple little proggies to code through: like a bouncing ball, or gadget to help the kids use the computer - like a timer to shut down the browser!  (Working on your homework? - damn straight you are!) |
|||
|
10 Jan 2008, 05:47 |
|
|
Madis731 10 Jan 2008, 07:11
@AlexP: How is LOC relative to speed? The site is about speed, not codesize
 Lets benchmark your Euclidean! Are you sure it works on EVERY CPU equally well?
Because modern CPUs are "backward-optimization-compatible" meaning that faster Core 2 code works faster on P4, III, II etc. So if your algorithm really is faster today - we can help this site to keep on updating. Actually I conducted some tests: Code: Compiler and switches used: E:\>icl /Ox /QxT /Qip /Qvec-report3 GCD.c Intel(R) C++ Compiler for applications running on Intel(R) 64, Version 10.0 Build 20070809 Package ID: W_CC_C_10.0.027 Results: E:\>GCD.exe 1,92703853 Input values were: 1, 92703853 Timers: Naive - 667319496 Modern - 785205048 BINGCD - 848798508 VilleM - 468 Result values: a=1, b=1, c=1, d=1 E:\>GCD.exe 10,1000000000 Input values were: 10, 1000000000 Timers: Naive - 719499768 Modern - 865184016 BINGCD - 915700596 VilleM - 408 Result values: a=10, b=10, c=10, d=10 E:\>GCD.exe 832648,38745 Input values were: 832648, 38745 Timers: Naive - 2628 Modern - 3084 BINGCD - 3084 VilleM - 1200 Result values: a=1, b=1, c=1, d= E:\>GCD.exe 0,0 Input values were: 0, 0 Timers: Naive - 600 Modern - 216 BINGCD - 180 VilleM - 168 Result values: a=1, b=1, c=1, d=0 ;!!!!! Last one seems to be inconsistent with other three ^o) why? And yes - debugging is a way to go too. I totally forgot about that. After OllyDBG, get yourself known to FDBG (Feryno Debugger) too if you're going to write for 64-bit OSs Win64/Linux64. But we ware that debugging threaded applications is very bad. If you're talking about Creating a Window then already there are message loops that are threaded so OllyDBG doesn't work as smoothly as for programs without a window. |
|||
|
10 Jan 2008, 07:11 |
|
|
bitRAKE 10 Jan 2008, 10:04
Code: ; Extended Euclid's algorithm ; non-recursive version, from Knuth ACP vol. 2, pg. 302 section 5.5.2 Algorithm X ; return: ; GCD(eax,edx) = ECX = A*EAX + B*EDX ; ECX unsigned; EAX,EDX signed eGCD: pushad mov esi,0 ; u1 mov edi,1 ; v1 mov dword [esp+28],1 ; u mov dword [esp+20],0 ; v jmp .x .0: div ebp mov ebx,esi mov ecx,edi xchg [esp+28],esi xchg [esp+20],edi imul ebx,eax imul ecx,eax sub esi,ebx sub edi,ecx mov eax,ebp .x: mov ebp,edx test edx,edx mov edx,0 jne .0 mov [esp+24],eax popad retn |
|||
|
10 Jan 2008, 10:04 |
|
|
madmatt 10 Jan 2008, 10:59
You can go to my website for some windows/directx examples. Just click on the [www] at the bottom of this post to get there. If you want to re-compile the examples, just follow the directions posted on the website.
|
|||
|
10 Jan 2008, 10:59 |
|
|
AlexP 11 Jan 2008, 14:15
Here's my Euclidean algo - It uses div on every loop so it's probably pretty slow like u said
Code:
pusha
xor edx,edx
mov eax,[Lower]
mov ebx,[Higher]
;Euclidean Algo
@@: div ebx
cmp edx,0
je @f
mov eax,ebx
mov ebx,edx
xor edx,edx
jmp @b
;Print the GCD to console
@@: push ebx [Higher] [Lower] GCD
call [printf]
add esp,16
popa
push 0
call [ExitProcess]
I just like that it's seven lines, three of which are devoted to cmp/jmp. The StrLen function that I have seen a C compiler output is this: Code:
lea esi,ds:[eax+1]
@@: mov cl,ds[eax]
add eax,1
test cl,cl
jnz short (@b)
sub eax,esi
I used a fasm version of this code in a command-line parser function a whie back: Code:
lea ebx,[Message+1]
@@: mov cl,[eax]
inc eax
test cl,cl
jnz @b
sub eax,ebx
I still haven't worked on the extended euclidean, I should do that now... Have fun learning FASM~ |
|||
|
11 Jan 2008, 14:15 |
|
< Last Thread | Next Thread > |
Forum Rules:
|