flat assembler
Message board for the users of flat assembler.

Index > Heap > Future of Win32 ASM programming?


Will .NET kill Win32 API?
Yes, and we will not be able to program Win32ASM anymore
5%
 5%  [ 1 ]
Yes, but we will still be able to program Win32ASM
27%
 27%  [ 5 ]
No, and will keep programming Win32ASM the same way we do today
55%
 55%  [ 10 ]
None of the options (post it)
11%
 11%  [ 2 ]
Total Votes : 18

Author
Thread Post new topic Reply to topic
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
Answer the poll and comment Smile
Also post what will you do
(ex: Migrate to Linux or other OS, keep resisting with ASM on Windows forever, stop programming Shocked,...).
Post 02 Oct 2006, 19:07
View user's profile Send private message Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
voted "No, and will keep programming Win32ASM the same way we do today", and that's what I think, Win64Api then again is whole another issue I think... Confused


edit: w00t, 301post, I feel like an postwh*r* now Embarassed
Post 02 Oct 2006, 19:12
View user's profile Send private message MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
no, it will be something else. new API, x86-64 or something like that. not .NET
Post 02 Oct 2006, 19:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
I feel the same way, .NET or not, I'm almost sure there will be ABI for it anyway...
Post 02 Oct 2006, 19:55
View user's profile Send private message MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Win32 support will remain for a long time - just see how long win16 has been supported. That is finally being phased out with 64bit windows, though.

Now, from my understanding (which might very well be wrong, since I haven't looked deeply into the matter), with VISTA the native API will be dotNET, and the Winxx subsystems will call that.
Post 02 Oct 2006, 22:29
View user's profile Send private message Visit poster's website Reply with quote
Ehtyar



Joined: 26 Sep 2006
Posts: 51
Ehtyar
Personally the winapi will remain, particularly given microsoft's obsession with backward compatibility (one of their few good traits). However, if the world of non-asm programmers (c/.net/java) continue to shun asm the way they have since hlls became so popular, fewer and fewer people will be coding in it, it will become a lost art.
Post 02 Oct 2006, 22:31
View user's profile Send private message Reply with quote
vbVeryBeginner



Joined: 15 Aug 2004
Posts: 884
Location: \\world\asia\malaysia
vbVeryBeginner
i personally like the idea inside win32 asm
everthing is DWORD, either it is an address or it is a value on a particular address.

and i personally think the data type verification shouldn't reside on a "api", it should be the IDE job (if a user want type check support).

eg.
CALLBACK WndProc (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)

so, the "ideal" way should allow

CALLBACK WndProc (DWORD hWnd, DWORD Msg, DWORD wParam, DWORD lParam)

imho... Smile
Post 03 Oct 2006, 07:20
View user's profile Send private message Visit poster's website Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
no, why do CALLBACK WndProc (DWORD hWnd, DWORD Msg,...) when the compiler SHOULD do it for you?

just like fasm does in this example:
hWnd dd 0
Msg dd 0
...
push [Msg]
push [hWnd]
call [WndProc]
;or
proc WndProc uses ebx esi edi, hWnd, Msg, ..
mov esi, [hWnd]
mov ebx, [Msg]
...

right? Wink
Post 03 Oct 2006, 12:47
View user's profile Send private message MSN Messenger Reply with quote
vbVeryBeginner



Joined: 15 Aug 2004
Posts: 884
Location: \\world\asia\malaysia
vbVeryBeginner
oh, that is an example, okasvi
that is what differ the asm and c code,
probably if we change all the windows header file, then we can achieve something like below in C
CALLBACK WndProc (DWORD hWnd, DWORD Msg, DWORD wParam, DWORD lParam)

coz imho, the attraction on win32 asm programming is "it spares us from those .... datatype like HWND, WPARAM, HFONT, HINTERNET or LPTSTR etc.

and the idea is to let the datatype checking/handling reside on the user IDE instead on the compiler.

so, if a user code
myfonth = CreateFont .... bla bla
the IDE would mark the myfonth as HFONT (internally)
so when compiling the code, the IDE would parse it one time first for datatype checking (if user so wish), then after that only send to compiler/assembler
so SendMessage(thewindowh, WM_SETFONT, myfonth,0) would works without complain.

so if user do SendMessage(thewindowh, WM_SETFONT, windowh,0), the IDE (not compiler/assembler) would notice the user about it.

just some of my thoughts
Post 03 Oct 2006, 19:34
View user's profile Send private message Visit poster's website Reply with quote
Ehtyar



Joined: 26 Sep 2006
Posts: 51
Ehtyar
In asm one has the flexibility to either ignore the hll data types (HWND, WPARAM, LPSTR etc) or take advantage of them. Personally i much prefer using them, makes naming variables far less of a hastle as it's already half obvious what it is by taking notice of the type it's declared as.
Post 04 Oct 2006, 22:40
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Asm is not a lost art -- as long as compilers "compile" we can always code in asm, even if the API changes. And that will also destroy Win32C, because the API is the same for HLL or asm. Even in java, there is an assembler, because all that data in java has to have some meaning somehow. As long as there is this "meaning" we will always be able to code in asm. That means asm is everywhere, because HLLs are based on asm. You can't remove the root, you must first remove the leaves Wink
Post 05 Oct 2006, 09:38
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
vbVeryBeginner wrote:

so if user do SendMessage(thewindowh, WM_SETFONT, windowh,0), the IDE (not compiler/assembler) would notice the user about it.


So, basically you want the IDE to have a partial assembler/compiler, and dumb the real assembler/compiler down so much that it can't do proper typechecking? Wooooonderful idea.

_________________
Image - carpe noctem
Post 05 Oct 2006, 09:53
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
I hate when people tend to say that "compilation" is slowing them down (and that's why they blame heavy optimizations)... maybe that's why it should be "dumbded" down so it's faster (by at most 1 second, anyway) Razz
Post 05 Oct 2006, 10:03
View user's profile Send private message Reply with quote
vbVeryBeginner



Joined: 15 Aug 2004
Posts: 884
Location: \\world\asia\malaysia
vbVeryBeginner
@fodder
coz, imho, what the assembler/compiler should do is translate the asm /c /c++ syntax into binary, period. (if it faces error, eg, missing param or impossible combination) it would stop there and echo back line number.

and the ide programmer use should be able to "assemble" the code at the time user key in. (check them at the moment they key in) by using some rules based on header file / etc inc. , eg. variable typo, undeclared function/proc, too large number, unclose loop, and etc

so, when the user finish his code, (he actually pass nearly half of the possible errors, except logic error), the time when he is coding, the ide already uses the time to identify all the common errors and the IDE uses that time to produce a more raw C code (everything dword or etc)

so, when send to compiler, it would compile maybe too fast that you don't have to wait :p (coz the compiler don't have to read the .h files anymore)

coz i think the future programming is more to extend the power of ide and let the ide establishes unique style of programming process.

well, maybe it is nice if somebody got some statistic on the timing used by compiler/assembler on various process. eg getting defined value, parsing, checking, optimize and assembly.

btw, it is just idea, :p until somebody code it Smile
Post 05 Oct 2006, 16:40
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
It's a pretty silly idea, vbVeryBeginner - C/C++ has static typing for a good reason. Also, the typechecking doesn't take much time, it's the optimization phase that pulls teeth out - and that will not benefit in any way from using dumb types, perhaps the contrary (on code quality, that is).

"Everything is a dword" is pretty lame anyway. And it isn't true if you want code to be portable between 32/64bit. It would also be pretty impractical in a HLL, unless you want to type "varname.typename.fieldname" instead of "varname.fieldname"...
Post 05 Oct 2006, 21:48
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.