Так что и в данном случае я просто считаю, что это хорошая школа программирования для меня (!)
К тому же, те макросы, которые я делаю, возможно, окажутся полезными другим людям для других целей.
Пожалуй единственное с чем я согласен в данной дискуссии.
Насчёт:
и чтоб программисты всего мира работали друг на дружку . Асмом занимаются не случайные люди в том смысле, что, IMHO, что их неустраивают существующие языки верхнего уровня (типа BASIC :-)), по разным причинам от банального желания выделяться среди окружающих, до вполне осознанных вроде "производственной необходимости" (например отсутствие возможности реализовать, какие то функции). А объединяет их, как мне кажется, не желание безоговорочно подчиняться чужим мнениям, и попытка ввести, какие либо новые модели или стандарты в существующий язык Ассемблера либо умрёт на процессе обсуждения (данная тема тому пример) либо потеряет смысл т.к. для реализации одних и тех же функций будет слишком много вариантов, которые будут иметь своих сторонников.
В кратце это будет невозможно, потому, что договориться не смогут.
А о самой необходимости ООП в АСМ могу сказать только одно: АСМ есть образ мышления компьютера и человеки программирующие на нём используют его потому, что такой образ мышления им ближе, но как говорят "На вкус и цвет товарищей нет" поэтому, мне кажется, что лучше иметь один инструмент (макросы к примеру) позволяющий каждому программеру использовать его для конкретно своего удобства, чем несколько отвечающих понятиям об удобстве несуществующих усреднённых групп программеров.

S.T.A.S.
там ещё букву м надо добавить
Не пользовался. Но человек спросил об ООП в АСМе, а по тому, что я о нем слышал это то, что он ищет, возможно.

2masquer:
А мне не в лом набрать первые буквы, а там ИДЕ достроит :)
А у меня вообще слепой десятипальцевый способ набора, мне лишние пару кило написать - разминка перед боем.

Вообще, на ассеблере, как правило, крупные проекты не пишутся
Гы, даже не знаю что на это сказать! Сразил! Ты мой довод, превратил в свой! Мастер! - а я хочу чтоб писалось!

По поводу скорости - спорный вопрос.
Вопрос можно, боюсь ошибиться, а ты вообще в ООП писал? Просто такое ощущение, что (это догадка, заодно ответь угадал я или нет) ты семестр в универе пробовал писать курсачь в объектах, но до этого ты долго писал в процедурах, ты не понял смысла в ООП, он тебя раздражает, и, успешно сдав курсач, ты вернулся к процедурам? Ну прав я или нет?

Это на высокоуровненых языках так, я на асме почему и пишу
Ввиду предыдущего предположения - трудно судить о вкусе устриц, не разу их не попробовав.

Покажи мне хоть одно ИДЕ которое будет такое поддерживать для ассемблера.
сорри не догнал это ты про что? если это про моё вложенность названий: MainForm.ButtonCancel.Handle то смею тебя уверить это возможно, и причем тут IDE?

мне еще ассеблерные сорцы индусов и прочих китайцев осталось почитать :)))
Батенька, а вас не Адольфом ли кличут? - Глупо помоему, китайцев (как пример) миллиард - ну хоть один то из них толковый найдется? И кто пострадает от того что китаец напишет чтото толковое, чем другие (ну допустим хотя бы один) смогут пользоваться?

Имхо, даже сама идея утопична.
Вообще это имхо и тут конечно не предирёшься, но, лет пятьдесят назад, идея компа на столе - была утопична.

JaDS
за работоспособность кода не ручаюсь не проверял, но схему я обрисовал

Да, идея понятна.. Я пытаюсь двигаться примерно в том же направлении,
но вот макросы "macro foo, [name]" я писать ручками не хочу. Их генерацию я возложил на плечи CLASS/ENDC.

Первоначально, я за основу взял этот макрос.
Как это работает, объяснить в 2х словах у меня не получится, т.к. я сам вникал приличное время.. :)
Смысл здесь примерно такой:
Есть макросы DWORD/BYTE/etc - как бы базовые типы данных.
Когда они находятся ВНУТРИ CLASS/ENDC - они составляют список параметров __class.fields для макроса __class.define, который в свою очередь создает новые макрос и структуру "name". Если они "снаружи", то аналогичны DD/DB/etc..

Вот сырой рабочий пример, что это дает:

CLASS	MSGH
WORD	ID		;;  message identifier
DWORD	Handler		;;  jump address
ENDC

CLASS	$Wnd		;;  \/ default values of fields
;;  class data
DWORD	handle				;;  handle to the window
DWORD	dwExStyle,	0		;;  extended window style
.......
MSGH	MsgHandle,	WM_NULL,$Wnd.WndProc.WM_NULL	;;  by default do nothing
;;  class procs
METHOD	Create,		$Wnd.Create	;;  exported procs for direct calls
......
ENDC

;;  
CLASS	$ConWindow
;;  inherited window data
!$Wnd	,,ConWindow.WindowName,,,,ConWindow.%CharWidth*ConWindow.%Collum  ns,ConWindow.%CharHeight*ConWindow.%Rows,\
\;;  message handlers
,<WM_DESTROY,$Wnd.WndProc.WM_DESTROY>;ConWindow.WM_DESTROY>	;;  infrequent message should be at odd position
MSGH,	WM_PAINT,ConWindow.WM_PAINT	;;  frequent messages should be at even
MSGH,	WM_CREATE,ConWindow.WM_CREATE
.......
MSGH,	WM_NULL,$Wnd.WndProc.WM_NULL	;ConWindow.Default
;;  console related stuff
DWORD	hFont, FALSE
DWORD	pData, FALSE
ENDC

Con $ConWindow  ;;  "объект"
.....
invoke	Con.Create  ;;  вызываем "унаследованный" метод 

Собственно, на этом пока все.
Сейчас начал с нуля переделывать этот набор макросов - в старом не получалось нормально "избавиться от промежуточного поля old".
Так что пока еще надо много чего добавлять / переделывать - старый формат не совместим.
Так что в ближайшем будующем думаю будет и так:
Con.Create ;; вызываем "унаследованный" метод
Потом будут и виртуальные методы и прочая..

Пока моя задача - реализовать некоторую базу - макросы.
Потом уже буду добавлять то, что генерирует код и т.п.

Т.е. чтоб в препроцессор были встроены дерективы описания сложных структур данных - этоим я и занимаюсь.
Но в препроцессор не лезу - стандартных макросредств FASM'а вполне хватит.

Пока делаю простой пример с 2мя окошками - для отладки всех этих макросов.
Дальше видно будет..

masquer
Мне тоже не в лом набрать первые буквы, но экспериментов я не боюсь.

я на асме почему и пишу - мне гибкость нужна и отсутствие ограничений - я сам себе и оптимизатор, и компилятор и еще Бог знает кто :)

Хм.. это как раз мои причины..
Помимо этого мне приходится жить с формальностями, которые диктует ось.
Вот я и подумал: а что мне мешает сделать, к примеру, одну WndProc для всех окошек - я б и DispatchMessage убрал бы, но в XP это хреново работает.
Так я и начал формально собирать разрозненные DWORDы в некоторые логически связанные блоки в сырцах..
А вот слепо следовать принципам ООП, которые я до конца не принимаю - это не мое..

В общем-то я прекрасно понимаю вашу позицию - есть отработанные методики приносящие вам требуемый результат.
Я вот только проснулся, а привык к меткам вида LS22_E - ну кому сейчас это надо? Сорцы-то в память целиком помещаются :)

JaDS
Сразил! Ты мой довод, превратил в свой! Мастер! - а я хочу чтоб писалось!
Вот когда напишешь - тогда и обсудим (как ты там говорил - вкус устриц?) Теоретизировать можно до пены у рта...

Просто такое ощущение, что (это догадка, заодно ответь угадал я или нет) ты семестр в универе пробовал писать курсачь в объектах, но до этого ты долго писал в процедурах, ты не понял смысла в ООП, он тебя раздражает, и, успешно сдав курсач, ты вернулся к процедурам? Ну прав я или нет?
Я тебя сейчас жутко разочарую и, возможно, придам новую энергию твоим расследованиям и словоизлияниям - я на программера вообще не учился, ни разу, о чем не жалею ни капли :))) Но польщен таким вниманием! А на ООП я писал - и внешнюю и внутренние стороны исследовал (больше внутреннюю реализацию, если честно)

вложенность названий: MainForm.ButtonCancel.Handle то смею тебя уверить это возможно, и причем тут IDE?
Ну как же - ты же за большие проекты ратуешь, как же тут без ИДЕ - или в notepad-е писать?

а вас не Адольфом ли кличут?
[глядя в потолок] поменять подпись себе, что-ли? :))))
Ладно, считай это не национальностями, а именами нарицательными :))))))

ну хоть один то из них толковый найдется?
пытался, искал, и не только я - увы. Может ищу не там :)

И кто пострадает от того что китаец напишет чтото толковое, чем другие (ну допустим хотя бы один) смогут пользоваться?
Да ради Бога - пользуйся на здоровье

S_T_A_S_
а что мне мешает сделать, к примеру, одну WndProc для всех окошек
Субклассирование, например :) Одну для всех не получится - неудобно будет, имхо (если ты имеешь в виду то, как, например это в WTL сделано)
Я на "ты" - ничего?

"...Вот я и подумал: а что мне мешает сделать, к примеру, одну WndProc для всех окошек - я б и DispatchMessage убрал бы, но в XP это хреново работает..."

Странно, у меня в коде только одна WndProc для всех HWNDs - и всё работает.
А почему надо убирать DispatchMessage()?

pas
Не пользовался. Но человек спросил об ООП в АСМе, а по тому, что я о нем слышал это то, что он ищет, возможно.

Один мой знакомый решил как-то получить на делфи мааленький экзешник. На второй день бросил затею :)
"HLA - это полная ересь, только игра во 2х Героев поможет очиститься от скверны" - цитата с RSDN (с) Aquila.


АСМ есть образ мышления компьютера и человеки программирующие на нём используют его потому, что такой образ мышления им ближе

Во! Таким же естественным для проца явлется косвенный вызов подпрограммы по адресу, хранящемуся в какой-то таблице.
Причем, это занимает меньше места в определенных случаях и дает некоторые другие плюсы.

Я кстати, не ввожу никакие стандарты.
Я все делаю исключительно для своего удобства.
А помимо всего прочего - мои макросы позволят (некоторые эксперименты были) импортировать объявленные структуры (есть проблемы только с UNION) и описания COM объектов прям из Сишных хидеров после их доработки - дведу до ума макросы STRUC / DECLARE_INTERFACE - он работает на основе CLASS/ENDC.

Один мой знакомый решил как-то получить на делфи мааленький экзешник. На второй день бросил затею :)
Я как-то видел исходники, которые на делфи компилировались в очень маленький экзешник. Там, правда, чистый апи и ничего лишнего не было

masquer
Ничего. Субклассирование для меня слишком сложно, к тому же мне не надо много окошек.
Пока выгдядит так:

;;==================================================================== =======
;;  window procedure
proc	$Wnd.WndProc ,	hwnd,uMsg,wParam,lParam	
begin
	invoke	GetWindowLong,	[hwnd],GWL_USERDATA	;;  pointer to SWnd object
	movzx	edx, W[uMsg]		;;  MS allows to use only WORD
	cmp	dx, WM_NCCREATE		;;  shorter than "cmp Edx, WM_NCCREATE"
	je	.WM_NCCREATE		;;  the only message to be processed
	;cmp	edx, WM_DESTROY		;;  this should be done in some object
	;je	.WM_DESTROY
	or	eax, eax
	je	.Def			;;  not a SWnd window
	push	ebp
	mov	ebp, eax		;;  prepare pointer for use
	add	eax, $Wnd.MsgHandle	;;  message table
.rep:	shl	eax,1	;;  the result of these 2 lines is the same as
	shr	eax,1	;;  "and eax, 7FFFFFFFh", but one byte shorter
@@:	movzx	ecx, W[eax+MSGH.ID]	;;  get element from table
	add	eax, sizeof.MSGH	;;  next table element
	or	ecx, ecx		;;  if zero, the end. process default
	je	.WM_NULL
	cmp	ecx, edx		;;  check message
	jne	@b			;;  not our message
	mov	eax, [eax+MSGH.Handler-sizeof.MSGH] ;; get address
	or	eax, eax		;;  check type. prog or new table
	js	.rep	;;  new table. the sign bit will be cleared abowe
	call	eax			;;  call msg_handler:
;;  proc	msg_handler ,	MSGHP,hwnd,uMsg,wParam,lParam
;;  msg_handler should return back here using retn instruction 

;;  predefined message handlers
.WM_NULL:
	pop	ebp
.Def:	if	..STACKFRAME eq .stdcall.EBP	;;  this isn't needed
			leave	;;  just some remark
		end if		;;  in the case of changing stackframe
	jmp	[DefWindowProc]
.WM_NCCREATE:
	mov	eax, [lParam]	;;  Pointer to the CREATESTRUCT structure
	mov	edx, [hwnd]	;;  this parameter is already valid
	mov	eax, [eax+CREATESTRUCT.lpCreateParams]	;;  window object address
	mov	[eax+$Wnd.handle], edx	;;  store hwnd
	invoke	SetWindowLong, edx, GWL_USERDATA, EAX	;;  pointer to SWnd object
	jmp	.Def
;;  this is called by above "call eax"
.WM_DESTROY:
	invoke	PostQuitMessage,0
	retn
endp

AsmGuru62
Странно, у меня в коде только одна WndProc для всех HWNDs - и всё работает

Судя по примерам из MSDN, рекомендуется использовать различные для окошек, которые по-разному обрабатывают сообщения.. Или Subclassing a Window

А почему надо убирать DispatchMessage()?
Ну в общем-то не надо, но можно бы..
Что делает эта штука, кроме как вызывает мою же WndProc после блуждания по dll?
Во всех системах до XP это работает без проблем, а вот в последней МС зделали GhostWindow - так что есть некоторые проблемы с отображением окна, если ее пропускать.

2S_T_A_S_:
прям из Сишных хидеров
А вот это даже я не одобряю, подкладывать асм под сишные хедеры - бррр. Это конечно упростит жизнь, но лучше напрячься и переделать под асм.

По поводу делфей:
не знай к чему этот разговор завели, но (Delphi 6):
1) самая маленькая прога (begin end.) - 8kb
2) с использованием KOL - 15kb
3) с использованием VCL - 351k

И вот тут есть один ньюанс. KOL тоже писал человек хорошо относящийся к асму, пример:

function TCanvas.GetBrush: PGraphicTool;
asm
        MOV      ECX, [EAX].fBrush
        INC      ECX
        LOOP     @@exit

        PUSH     EAX
        CALL     NewBrush
        POP      EDX
        PUSH     EAX

        MOV      [EDX].fBrush, EAX

        MOV      [EAX].TGraphicTool.fOnChange.TMethod.Code, Offset[TCanvas.ObjectChanged]
        MOV      [EAX].TGraphicTool.fOnChange.TMethod.Data, EDX
        MOV      ECX, [EDX].fOwnerControl
        JECXZ    @@1

        PUSH     [ECX].TControl.fBrush
        MOV      ECX, [ECX].TControl.fColor
        MOV      [EAX].TGraphicTool.fData.Color, ECX
        POP      EDX
        TEST     EDX, EDX
        JZ       @@1

        CALL     TGraphicTool.Assign
@@1:    POP      ECX

@@exit: XCHG     EAX, ECX
end;

Там всё в таком стиле (kol.pas - 1.84Mb - 62 тысячи строк). Как можете заметить от делфей тут взято только ООП. Всё остальное на асме, видимо человек так и не нашел "нормального" ООП в асме (хотя ИДЕ у делфей тоже ничего, дико FRESH напоминает:). Так вот, парой кликов мышкой я могу в KOL сделать интерфейс (формы кнопки меню ...) И я не потеряю сильно ни в коде ни в производительности, а вот конкретный критический кусок я пишу в асме (хотя судя по коду KOL - весь интерфейс критичен:) - но это изврат, делфи накладывает свой отпечаток, да и встроенный ассемблер - убого.

Вот хотелось бы похожее только в асме, чтоб можно было быстро собрать интерфейс, а потом уделять внимание только критичным участкам. - Опять вернусь к вопросу - Ну и пиши это в делфях/си - дело в том что асм намного более гибок чем встроенный асм, и хочется совместить эту гибкость асма и мощьность ООП.

PS:
при чем тут вообще делфя?

[ S_T_A_S_: Один мой знакомый решил как-то получить на делфи мааленький экзешник. На второй день бросил затею :)]

Ага.., я недавно пробовал, результаты для Delphi7 exe'шник ~14Kb и dll'ка ~13Kb. Там не удаётся избавиться от первого call'а, а в нём такой мусор что глаза на лоб лезут..
Короче, не нужен асм'у OOP, у него другое предназначение, иначе так можно все языки испоганить, превратив в Delphi ;-)

[ JaDS: 1) самая маленькая прога (begin end.) - 8kb]

Это было только на 6-й, а на 7-й в два раза больше ;-)))

>Короче, не нужен асм'у OOP, у него другое предназначение, иначе так можно все языки испоганить

Но-но! Ты это, сапогами-то в душу не лезь!
Реюзабильность кода - это очень важная штука. Давай я тебе проект дам и дам две недели на завершение. А ты мне за эти две недели настрадай все с нуля. Ну как, не поплохело? Нужен асму ООП и еще как! Глядишь, так и юзать начнут хоть когда-то. А KOL с ООП вы не мешайте! Есть разница просто в переписывании процедуры на асме и мышлением на уровне ООП.

S_T_A_S_
JaDS

ОРЛЫ! Я за вас кулаки держу!