flat assembler
Message board for the users of flat assembler.

Index > Windows > Future Of Windows Programming In FASM

Author
Thread Post new topic Reply to topic
Masood.Sandking



Joined: 12 Jan 2012
Posts: 65
Location: Iran
Masood.Sandking
Hi!
Please tell me about the future of Windows programming in FASM... Beside Microsoft technologies and policies... I'm a little confused about this...
Post 19 Sep 2012, 18:24
View user's profile Send private message Yahoo Messenger Reply with quote
nmake



Joined: 13 Sep 2012
Posts: 193
nmake
FASM is created by a single man and seems to be maintained by a single man as far as I can tell. My opinion is that he should begin now to recruit people to help him with the project. Because if he grow tired someday all the suddenly, there might not be enough enthusiasm for other people to take over the project. If he waits too long to recruit helpers the project may die some day. We've seen this before.

When it comes to windows programming, it is an ever growing hairball of layers, com and general hellfire for an assembly programmer. It's only going to get more complex, but the good thing is that we have people enough in the community to create include files for us.

When it comes to microprocessors, assembly has a bad future (if we speak of in the far future ahead). More and more instruction sets keep coming all the time. When die size become very small, down to 5-10 nanometre we can fit alot of instruction sets on the cpu. The problem here is that an assembly programmer will not be able to control all of these instructions, we're talking thousand of instructions, it will simply become too much for an assembly programmer to keep control of all of them due to share numbers. Because of this assembly will move from "rare" to "extremely rare" where it is used only in situations where you absolutely need to optimize a piece of c++ generated code or for coding operating system specific code. A c++ compiler is an expert at producing code for parallell execution (using many execution units at the time). As we produce more execution units in the future, it is going to get hard to synchronize all of them using manual assembly. This is where the compiler will do outstanding work.

In the old days, hardware was designed with an absolute minimum of features so that you could do the most important and relevant work a computer needed to do. Today die size is shrunk so much that we not only put what we need on the chip, we put luxury on it too, now we put all kinds of stuff onto it, not because we need to, but because we can. And this is going to continue to grow.
Post 19 Sep 2012, 19:03
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1412
Location: Toronto, Canada
AsmGuru62
I am writing an unusual IDE for FASM.
Work on it goes slowly, however - sometimes very slow.

It will introduce an idea of OO Programming and ability to reuse code, which will in turn provide for creation of large projects, where programmer
can simply use some classes which were coded and debugged before.

It is based on code generation from a pseudo-code.
Code generation opens some very cool possibilities, like
being able to profile the program or solve the duplicate text issue, which I have seen recently in a thread.

Example:

Pseudo code:
-----------------
eax = L"Some text"

Generated code:
--------------------
s6355 du 'Some text',0 ; <-- into .data section
...
mov eax, s6355 ; <-- into .code section

You can use text constants in a function calls:
---------
api.MessageBox (L"Message Text", L"Caption", 0, MB_OK)

Stuff like that, where optional code generation allows for a lot of possibilities.
Like an option to base local variables on EBP or on ESP.
Or an option to clear all locals to zeroes:

Code:
local =0
{
 HANDLE  hModule;
    TCHAR   Path [256];
}
    
Post 19 Sep 2012, 19:48
View user's profile Send private message Send e-mail Reply with quote
Masood.Sandking



Joined: 12 Jan 2012
Posts: 65
Location: Iran
Masood.Sandking
Thank guys...
Also i want to know about .net Framework, WinRT and other dreams of Microsoft in future beside Windows programming in FASM using old APIs. Is there another style of programming in FASM? Should be there...?
Post 19 Sep 2012, 20:10
View user's profile Send private message Yahoo Messenger Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1412
Location: Toronto, Canada
AsmGuru62
I think .NET is evolving nicely -- it has been around for 10 years, IIRC.
I would call it a major Windows Programming tool.
There is hardly job description without mentioning .NET and C#.
But it is boring, no pointers and no memory dumps. Very productive, however.
Post 20 Sep 2012, 14:09
View user's profile Send private message Send e-mail Reply with quote
bzdashek



Joined: 15 Feb 2012
Posts: 147
Location: Tolstokvashino, Russia
bzdashek
AsmGuru62, some pointer functionality (or resembling pointers) can be achieved. I experimented with C# and DLL created on FASM, and if it might be of any interest to anyone, I can post source code here. I just need to find it in my heap Smile
Post 21 Sep 2012, 06:15
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1412
Location: Toronto, Canada
AsmGuru62
bzdashek, you do not need to post the code, it is OK - I am OK with C# as it is.
I inherited a large project on C# and just keep it live, so customers are happy.
Post 21 Sep 2012, 12:34
View user's profile Send private message Send e-mail Reply with quote
bzdashek



Joined: 15 Feb 2012
Posts: 147
Location: Tolstokvashino, Russia
bzdashek
Oh, ok Smile Sorry.
Post 22 Sep 2012, 08:50
View user's profile Send private message 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 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.