WinApi und Assembler -> Freund oder Feind?^

[markusrw]

Ich versuch mich gerade an Win32 Programme in Assembler, weil ich im Prinzip die ganzen Grundlagen vorher schon beherrsche, irgendwie erstaunlich.^^

Nun hab ich bemerkt, dass ein Programm, hier ein einfaches Fenster, in Assembler 2,5 kb groß ist und im Gegensatz dazu ein Fenster, welches mit C erstellt worden ist 57 kb groß ist.

Nun stell ich mir die Frage, ob es net besser wäre, wenn ich in Zukunft meine Winapi Programme alle über Assembler schreibe, weil ich irgendwie finde, dass es im Grunde das selbe ist, als wenn ich meine Programme über Winapi C oder Winapi Assembler schreibe.

ATOM MyRegisterClass(HINSTANCE hInstance)
{
	WNDCLASSEX wcex;

	wcex.cbSize = sizeof(WNDCLASSEX);

	wcex.style			= CS_HREDRAW | CS_VREDRAW;
	wcex.lpfnWndProc	= WndProc;
	wcex.cbClsExtra		= 0;
	wcex.cbWndExtra		= 0;
	wcex.hInstance		= hInstance;
	wcex.hIcon			= LoadIcon(hInstance, MAKEINTRESOURCE(IDI_TEST));
	wcex.hCursor		= LoadCursor(NULL, IDC_ARROW);
	wcex.hbrBackground	= (HBRUSH)(COLOR_WINDOW+1);
	wcex.lpszMenuName	= MAKEINTRESOURCE(IDC_TEST);
	wcex.lpszClassName	= szWindowClass;
	wcex.hIconSm		= LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

	return RegisterClassEx(&wcex);
}

mov wc.cbSize,SIZEOF WNDCLASSEX
  mov wc.style,CS_BYTEALIGNCLIENT or CS_BYTEALIGNWINDOW
  mov wc.lpfnWndProc,OFFSET WndProc
  mov wc.cbClsExtra,NULL
  mov wc.cbWndExtra,NULL
  push hInstance
  pop wc.hInstance
  mov wc.hbrBackground,COLOR_BTNFACE+1
  mov wc.lpszMenuName,NULL
  mov wc.lpszClassName,OFFSET szClassName
  invoke LoadIcon,NULL,IDI_APPLICATION
  mov hIcon,eax
  mov wc.hIcon,eax
  mov wc.hIconSm,eax
  invoke LoadCursor,NULL,IDC_ARROW
  mov hCursor,eax
  mov wc.hCursor,eax

  invoke RegisterClassEx,ADDR wc

Also für mich sieht das Beispielsweise fast gleich aus...
Oder vielleicht meint ihr ja sogar, dass sich der Aufwand gar nicht lohnt und man auf die wenigen KB's, die man einsparen kann, auch verzichten darf.^^

[Nobuo T]

Tja, das sind dann halt irgendwelche Standard-Libraries mit Fehlerbehandlungs-, Ausgabe- und dazugehoerigen Initialisierungs-Dingen, usw.
Wenn man es wirklich darauf anlegt, bekommt man so ein C-Programm sicher auch auf eine aehnliche Groesse runtergebrochen.

Weiter tendiere ich dazu, dieses MASM Macro-Gefrickel nicht mehr wirklich als Assembler anzusehen... Fuer kleinere Sachen laeuft das tatsaechlich bald auf einen aehnlichen Aufwand hinaus, wie eine Implementierung in C.

[markusrw]

Nobuo T schrieb:

Weiter tendiere ich dazu, dieses MASM Macro-Gefrickel nicht mehr wirklich als Assembler anzusehen... Fuer kleinere Sachen laeuft das tatsaechlich bald auf einen aehnlichen Aufwand hinaus, wie eine Implementierung in C.

Wie meinst du das?

[TGM]

Freund.

wenn ich mir angucke, wie nervig all diese Datentypconvertierungen etc. sind, dann kommt mir edes mal, wenn ich in WinAPI C/C++ code die Galle hoch.. asm ist da viel netter^^

[Nobuo T]

markusrw schrieb:

Nobuo T schrieb:

Weiter tendiere ich dazu, dieses MASM Macro-Gefrickel nicht mehr wirklich als Assembler anzusehen... Fuer kleinere Sachen laeuft das tatsaechlich bald auf einen aehnlichen Aufwand hinaus, wie eine Implementierung in C.

Wie meinst du das?

Schau dir doch zB. mal diesen MASM-Beispielcode in deinem "Frage zum Assembler Buch"-Thread an. Der Anteil von MASM-Spezifischen Macro-Scripts (while, if, invoke, etc. ist im eigentlichen Sinne kein Assembler-Code) und Strukturierungen im Code ist bald hoeher als der von tatsaechlichem Assemblercode, dh. Mnemonics.

[markusrw]

Nobuo T schrieb:

markusrw schrieb:

Nobuo T schrieb:

Weiter tendiere ich dazu, dieses MASM Macro-Gefrickel nicht mehr wirklich als Assembler anzusehen... Fuer kleinere Sachen laeuft das tatsaechlich bald auf einen aehnlichen Aufwand hinaus, wie eine Implementierung in C.

Wie meinst du das?

Schau dir doch zB. mal diesen MASM-Beispielcode in deinem "Frage zum Assembler Buch"-Thread an. Der Anteil von MASM-Spezifischen Macro-Scripts (while, if, invoke, etc. ist im eigentlichen Sinne kein Assembler-Code) und Strukturierungen im Code ist bald hoeher als der von tatsaechlichem Assemblercode, dh. Mnemonics.

Das stimmt, aber im Vergleich zu HLA ist MASM doch wirklich noch ein echtes Assembler.^^
Aber naja ok, wäre NASM ein "echteres" Assembler als MASM, hab nämlich NASMX gefunden, soll auch NASM32 heißen, damit soll man auch sowas erstellen können.

[abc.w]

Hallo,

habe grade was ausprobiert:

> strip --version
GNU strip 2.17.50 20060824
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
> dir
-a---        28.12.2007     11:46      25306 devcaps1.exe
> strip devcaps1.exe
> dir
-a---        19.05.2008     21:38       8704 devcaps1.exe

Und die exe scheint noch lauffähig zu sein... Cool, da steckt Faktor 3 dahinter, ohne stundenweise Assemblercode zu debuggen...

[Nobuo T]

markusrw schrieb:

[...]Das stimmt, aber im Vergleich zu HLA ist MASM doch wirklich noch ein echtes Assembler.^^

Naja, diese Art der Macro-Programmierung, die in diesen MASM-Beispielen beschrieben wird, aehnelt wie gesagt bald eher einer Hochsprache. So gesehen ist MASM eher schon etwas mehr als nur ein Assembler.

markusrw schrieb:

Aber naja ok, wäre NASM ein "echteres" Assembler als MASM[...]

Nein. Ein besserer vielleicht, aber das geht am Thema vorbei. :p

markusrw schrieb:

[...]hab nämlich NASMX gefunden, soll auch NASM32 heißen, damit soll man auch sowas erstellen können.

Du meinst dieses Macro-Paket? Kenne ich nicht genau, aber wenn das auf etwas Aehnliches wie diese MASM-Scripts hinauslaeuft, frage ich mich, wieso du stattdessen nicht gleich in einer Hochsprache mit inline asm programmierst?
Irgendwann fuehrt es das Konzept eines Assemblers auch einfach ad absurdum.