cresta
секциями data при линковке и компиляции
Секции "склеиваются" .data? с .data?, а data с data.

cresta
OpenFileDialog не переделывал
Я так понял, что исправлял OpenFileDlg ибо ты сам написал "я от греха подальше исключил макрос reparg".

Пора закончить беспредметный разговор. Давай код и исходник, в котором по твоему мнению ошибка.

q_q
Убрал нагромаждение макросов и всё прояснилось. Заменил их обычной процедурой:
; ########################################################################

GetFileName proc hParent:DWORD,lpTitle:DWORD,lpFilter:DWORD
	
    LOCAL ofn          :OPENFILENAME 
    
    push edi
    mov ecx, sizeof OPENFILENAME
    mov al, 0
    lea edi, ofn
    rep stosb
    pop edi
    
    mov ofn.lStructSize,        sizeof OPENFILENAME
    m2m ofn.hWndOwner,          hParent
    m2m ofn.hInstance,          hInstance
    m2m ofn.lpstrFilter,        offset szFilterO
    m2m ofn.lpstrFile,          offset szFileName
    mov ofn.nMaxFile,           sizeof szFileName
    m2m ofn.lpstrTitle,         offset szTitleO
    mov ofn.Flags,              OFN_EXPLORER or OFN_LONGNAMES or OFN_FILEMUSTEXIST or OFN_HIDEREADONLY
	
    PrintLine
    PrintHex prevWnd
    PrintHex offset prevWnd
    PrintLine
    DbgDump offset hWnd, 4020
    invoke GetOpenFileName,ADDR ofn
    PrintLine
    PrintHex prevWnd
    PrintHex offset prevWnd
    PrintLine
    DbgDump offset hWnd, 4020    ;вот тут всё ясно видно
    mov eax, OFFSET szFileName
	
    ret

GetFileName endp

То, что делает GetOpenFileName из comdlg32 с секцией .data? можно посмотреть в аттаче. Там два файла: листинг самой секции и dump памяти непосредственно до и сразу после вызова GetOpenFileName. Как с этим бороться - не знаю, разве что переписать comdlg32 :)
Думаю теперь ясно, откуда растут ноги у проблемы.
jekyll
Спасибо за инфу про склейку секций.

_211634079__GetOpenFileName.zip

> То, что делает GetOpenFileName из comdlg32 с секцией .data? можно посмотреть в аттаче. Там два файла: листинг самой секции и dump памяти непосредственно до и сразу после вызова GetOpenFileName. Как с этим бороться - не знаю, разве что переписать comdlg32 :)

Сказки какие-то, никогда с GetOpenFileName не было никаких проблем, очевидно ошибка у тебя, но исходник ты почему-то упорно не хочешь показывать ;-)

cresta
Убрал нагромаждение макросов ... Заменил их обычной процедурой
Код нормальный, только не хватает определения/описания szFilterO, szFileName и szTitleO.

что делает GetOpenFileName из comdlg32 с секцией .data? можно посмотреть в аттаче
Тебе на кажется странным, что изменяются только 4-ре байта?

Спасибо за инфу про склейку секций
jekyll не упомянул, что сегмент неинициализированных данных (.data?) пристраивается следом за сегментом инициализированных данных (.data), начало пристраивания выровнено по границе двойного слова, и в результате оба сегмента попадают в одну секцию исполняемого модуля - .data.

Asterix
Сказки какие-то, никогда с GetOpenFileName не было никаких проблем, очевидно ошибка у тебя, но исходник ты почему-то упорно не хочешь показывать ;-)[/quote]
Видимо ты не смотрел дамп памяти. О исходнике:да не прячу я его, всё в 50 кб не влазит, я приаттачил только код, иконки и курсоры какие-нибудь подоткни и посмотри
q_q
„Тебе на кажется странным, что изменяются только 4-ре байта?“
Да,я пробовал по этим адресам подсунуть пустой буфер - по прежнему лепит на prevWnd, игнорируя этот буфер. Возможно где-то остался адрес prevWnd и эта ячейка затирается GetOpenFileName. Хотя от последнего доступа к prevWnd происходит много чего, и его адрес не сохраняется в регистрах. Непосредственно перед вызовом GetOpenFileName я просматриваю все регистры на предмет их содержимого - нигде адрес prevWnd не фигурирует. Да если бы и сидел в каком регистре адрес, то и что с того? Ф-ция не должна в любом случае переписывать что-либо по адресам, которые она сама не вычисляла.Imho. Ещё теоретически возможно: я запушил этот адрес и забыл про него, но в этом случае программа вылетала бы. Тоже отпадает.




1321258110__11.zip

cresta
Где cr.ico, Explorer.ico, Binocular.ico, plus.ico, replace.ico, del.ico, Hand.cur и возможно strtable.asm?

Вся папка под 300 кб, поэтому по частям :)
strtable.asm пока исключи, он не используется

914260863__Icons.zip

cresta
Мда.., я вижу что без masm v.8.2 мне скомпилить это не удастся.
Я бы советовал всё-таки не юзать в таком количестве макросы.
Попробуй для теста убрать весь побочный код и оставить только ту часть где GetOpenFileName ну чтоб файл запускался и указанный выше глюк тоже проявлялся.

cresta
strtable.asm пока исключи, он не используется
Так и сделал. Собралось даже без ресурсов. Потом собрал с ресурсами.

Попробовал под w2ksp4, xpsp1 и w98se. Внешний вид в аттаче (картинка из w2ksp4, под w98se аналогичная, под xp иконки чуть=чуть другие). Значение по адресу prevWnd смотрел в отладчике (OllyDbg) до и после вызова функции GetOpenFileName оно не изменялось.

70542581__NewFloat.gif

cresta
Удалил комментарии с вывода отладочной информации вокруг GetOpenFileName - значение prevWnd не меняется. Все под теме же тремя виндами.

q_q
„Удалил комментарии с вывода отладочной информации вокруг GetOpenFileName - значение prevWnd не меняется. “
Ты не написал, закомментировал ли в процедуре MenuItemsProc строки push prevWnd и pop prevWnd. Попробуй закомментируй их (всего 4 строки - по 2 на push и pop) и ещё раз сними дамп в GetFileName proc (до и после вызова GetOpenFileName)
Пробовал и в OllyDbg посмотреть- переписывает в ноль, пытаюсь разобраться в недрах GetOpenFileName.

cresta
Посмотри в момент когда будешь на этом коде в отладчике состояние флага направления:

  push edi
  mov ecx, sizeof OPENFILENAME
  mov al, 0
  lea edi, ofn
  rep stosb

Или добавь сюда команду cld, просто попробуй.
Мне лениво ставить masm8.2 чтоб скомпилить твой исходник и самому проверить, но
звёзды мне подсказывают что косяк может быть здесь.

Или ещё вариант, подключи этот файл что в аттаче к проекту вместо твоей процедуры и вызывай свою функцию, потом сообщи моя процедура тоже глючит?

_1287396622__GetFileName.asm

Asterix
„состояние флага направления:“
В процедуру входит с установленными флагами C,P,A,S флаги Z,T,D сброшены в ноль. Флаг D стоит в 0 вплоть до самого вызова GetOpenFileName, да собственно прям перед GetOpenFileName проверяю переменую prevWnd - она ещё не переписана, а при выходе из неё - уже ноль.
„сообщи моя процедура тоже глючит?“
Процедура из аттача работает также, как и моя, только окно диалога переместилось в левый верхний угол.