Зачем в программе процедура окна, если она ни разу не вызывается?

amvoz
if then while много ума не требуют. Это основы алгоритмизации, и этому можно даже обезьяну научить.

 

Это, простите, как ?
Если имеется ввиду шелл cmd.exe, то он как раз написан на С. Как впрочем почти вся (или весь?) Виндовс.

 

Ой ли... А это смотря какие задачи решать этими инструментами. Я написал... Ну написал, в общем. А ещё я написал программу решения японских кроссвородов на Pascal. Так, полмесяца баловался, ещё полмесяца тестировал и до сих пор не уверен. что правильно написал... С помощью всего лишь if then while...

 

Я имел ввиду, что когда Вы пишите "Hello, word!" на С Вы же не создаёте никакую оконную функцию и класс окна не регистрируете.
...Но дело не в этом, я стою на этой стезе и уходить с неё не собираюсь. И если я остаюсь здесь, значит оно мне надо. Ассемблер, значит, ассемблер. Со всеми вытекающими последствиями. В общем, уверен, что мы останемся друзьями.

 

Вам предстоит еще много открытий. В частности существование консольных приложений. Которым окно не требуется.
И С тут нипричем. Консольное "Hello world" можно написать на множестве языков, в т.ч. на асме.

 

amvoz
Это оффтоп, поэтому я ограничусь ещё этим сообщением и остановлюсь.

И да, и нет. Языки высокого уровня - всего лишь очередной уровень абстракции.
Начинаем с законов физики. Абстрагируемся, получаем транзисторы. Абстрагируемся ещё, получаем логический вентиль. Абстрагируемся, получаем VHDL (Verilog, System C) и программируемые цепи. Ещё абстрагируемся, получаем ассемблер. Ещё, получим си. Дальше модульное, декларативное, функциональное, объектно-ориентированное программирование, Prolog, Haskell, C++. Чем выше уровень абстракции, тем больше Вы можете охватить, но и тем больше ограничиваете свою власть. Кто хочет сразу результат без особых усилий, выбирает VB. Кто хочет реальную, приятную, почти неограниченную власть, тот выбирает ассемблер. Но за такой выбор извольте заплатить своим же временем.

А вот неправда. Императивный стиль - это значит мы ещё близки к архитектуре работы железа. Абстрагируемся от неё... Нравится логика? Возьмите OPAL. А ещё лучше Prolog. Эти языки Вам покажутся новыми мирами. Ну это так... для расширения кругозора. А нравится власть, возвращаемся к ассемблеру.

 

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

 

в юмор! Ты хочешь сказать, что пытался создать окно только для Hello world??? Убило просто. invoke MessageBox и будет тебе счастье.

А если серьезно, то ты сейчас не видишь абсолютно никакой разницы между языком и опреционной системой, и не понимаешь, что из них чем занимается

 

да уж - случай действительно близок к клиническому, только не со стороны ТС, а со стороны тех кто вместо того, чтобы просто и на пальцах ответить на простейшие вопросы развёл флуда уже на 2 страницы )
Между тем вопросы бегиннерса вполне нормальные и в книгах ответы на них по началу не всегда легко найти, а уж совет изучить сначала hi-level... вы бы ему ещё бейсик посоветовати, чтобы в апи разобраться )))

amvoz
Прототипы (в любом языке) нужны для того чтобы компилятор знал о количестве и типе параметров функции. Кстати если функция написана в тексте программы до того как она вызывается - то прототип не нужен, а нужен он если функция импортированная или расположена в конце программы.
Хорошим стилем программирования считается указание в прототипе не только типа, а и осмысленного названия аргументов функции, например:

Код (Text):

1. CreateWindowExA PROTO dwExStyle:DWORD, lpClassName:DWORD, lpWindowName:DWORD, dwStyle:DWORD, x:DWORD, y:DWORD, nWidth:DWORD, nHeight:DWORD, hWndParent:DWORD, hMenu:DWORD, hInstance:DWORD, lpParam:DWORD
2. CreateWindowEx equ <CreateWindowExA>

А если для импортируемой функции нужно просто указать суммарный размер и количество её параметров, то вместо PROTO можно использовать:

Если функция вызывается не через высокоуровневый invoke (который дополнительно проверяет параметры), а по адресу/метке

То прототип тоже не нужен - метку (имя функции) без параметров компилятор и сам найдёт в программе, даже если она расположена в конце программы после вызова функции.
Если в windows.inc нет нужной системной константы проверь свежая ли у тебя версия и если константы всё равно нет, то опиши её сам, взяв из заголовочных файлов *.h для С\C++, там есть все, если конечно версия заголовков не древняя (кстати если константа не описана, то компилятор на это будет ругаться, а не узнает её значение "как нибудь сам" ))

 

во первых существуют параметры QWORD, занимающие 8 байт в стеке, а во вторых, несмотря на то что параметры типа BYTE и WORD выравниваются на границу DWORD, их обработка в invoke отличается - посмотрите в отладчике как работает:

Код (Text):

1. .686
2. .model flat,stdcall
3.       option casemap:none   ; case sensitive
4.       include \masm32\include\windows.inc
5.       include \masm32\include\user32.inc
6.       include \masm32\include\kernel32.inc
7.       includelib \masm32\lib\user32.lib
8.       includelib \masm32\lib\kernel32.lib
9.  
10. ;==============================================================
11. .data
12. my_byte   db 12h
13. my_word   dw 1234h
14. my_qword  dq 1234567887654321h
15. szTitle db 'proto demo', 0
16. szMsg_1 db 'вызвана myProc_1', 0
17. szMsg_2 db 'вызвана myProc_2', 0
18. .code
19. ; --- прототипы ---
20. myProc_2 PROTO Arg_1:WORD
21.  
22. ; --- подпрограммы в начале - не нужен прототип ---
23. myProc_1 PROC Arg_1:BYTE, Arg_2:WORD, Arg_3:QWORD
24.     invoke MessageBox, NULL, addr szMsg_1, addr szTitle, MB_OK
25.   ret
26. myProc_1 ENDP
27.  
28. ;==============================================================
29. ; -------------------- основная программа ---------------------
30. start:
31.     invoke myProc_1, my_byte, my_word, my_qword
32.     invoke myProc_2, my_word
33.   invoke ExitProcess, NULL
34. ;==============================================================
35.  
36. ; --- подпрограммы в конце - нужен прототип ---
37. myProc_2 PROC Arg_1:WORD
38.     invoke MessageBox, NULL, addr szMsg_2, addr szTitle, MB_OK
39.   ret
40. myProc_2 ENDP
41.  
42. end start

так что MSoft прежде чем стебаться над бегиннерсом не мешало бы и матчасть подучить )

 

Имхо такие траблы от яву. invoke тоже элемент яву. Например у Пирогова нет ни макросов, ни invoke, ни include. Для начинающих лучше всё делать ручками.

 

Booster
имхо это тоже крайность, как и ранее прозвучавший совет начинать с чистого яву, а затем потихонечку переползать на асм (хотя дзен конечно же учение радикальное )
имхо использование hi-level конструкций: invoke, .if, и т.п.; макросов (чужих и своих) в асме как на этапе освоения так и в рабочих программах это самый удобный и правильный "срединный путь" рекомендованный Буддой Гуатамой )

 

Y_Mur
Ну начинай ТС без макросов, думаю у него никогда вопрос про прототип не возник. Я долго писал без макросов, и ничего, жив до сих пор, да и сейчас они мне не особо нужны. В отладчике invoke тоже нет. -)

Где почитать си письмена? Или Будда это Билли?

 

Booster
а я к макросам привык ещё с бегиннерства на тасме - имхо очень полезный иструмент - поволяет делать свой язык в языке - наглядно и полезно invoke меня сначала тоже раздражал, но когда пару раз он мне быстренько подсказал ошибку в передаче аргументов, которую обычно приходилось долго выуживать отладчиком изменил к нему отношение

например здесь )

 

Y_Mur
в масме инвок это вроде бы оператор а не макрос
а вот в фасме инвок это макрос

 

GoldFinch
я поэтому и перечислил через запятую

хотя ты прав, лучше через : и ; написать - исправил

 

Нет, я не пытался этого сделать

 

...Я вынужден защищаться.

Это во что же я так упёртый-то, а?
И вообще, молодой человек, запомните. Если я и упёртый, то только потому, что знаю (хотя, могу и ошибаться). Откуда? Допустим, прочёл. И вдруг увидел противоречие. Вот упёртость. И если я вижу, что написано:

"А на этапе транслирования ассемблер не имеет никакого понятия о том, что в природе существует какой-то ExitProcess... И чтобы он (транслятор) не ругался, мол, "кто такой, почему не знаю", нужно их "познакомить" - при помощи так называемого прототипа. Другими словами, прототип - это своего рода уведомление транслятора о том, что "немного попозже я собираюсь обращаться к товарищу ExitProcess, и форма вызова для него такая-то". Ну а далее следуют "паспортные данные" на этого товарища - сколько он "переваривает" параметров, и какой они должны быть размерности, дабы тот, не дай бог, не подавился." Вот здесь http://www.wasm.ru/article.php?article=1022004
И вдрг ивжу вопрос того парня, что у оконной функции нет прототипа- что я должен думать? И я не могу знать, что она не моя- не авторская (оказывается), ибо тело этой функции я пишу сам. Сам пишу тело функции! А значит, я должен именно уведомить транслятор... и так далее. Что нелогичного в моих умозаключениях? Я не знаю, что есть такой вид API функций- их прототип прописан.. Ну, то есть они с кем надо познакомлены, но тело их надо самому писать. Вот не мог я это предположить. Самостоятельно. Потому и переспрашивал постоянно... Тьфу.
Y_Mur разъяснил. Но понял бы он мой вопрос без постоянных утонений и переспрашиваний с моей стороны?..

В С же... Там интересная ситуация. В книге Стефана Кочана, допустим, он всегда писал прототипы. Даже так

#include <stdio.h>
void a (int s) {
s= 1;
}
int main(){
void a (int s);
a (2);
return 0;
}

Обратите внимание, если не писать прототип функции a, то программа будет работать всё равно! Короче, я и не писал. То есть задействовал к прототипам тогда, когда уж надо действительно и должного внимания на них не обращал. И не изучал соответственно. А надо было. Вот оно мне боком и вылезло. Век живи- век учись.