Нужно повторно использовать ReadBufferX, если не очищать эту переменную, то произойдёт замена части строки, пример: читаем первый раз строку: это тест читаем второй раз строку: not вывод во второй раз: not тест, как сделать чтобы выводилось только not Написал небольшой(рабочий) примерчик демонстирующий проблему. Если использовать разные переменные, тобишь обходиться без макросов, то всё нормально, но для повышения стилистики и простоты кода, желательно было бы разобраться с данным вопросом. .486 .model flat, stdcall option casemap: none include \masm32\include\windows.inc include \masm32\include\user32.inc include \masm32\include\kernel32.inc includelib \masm32\lib\user32.lib includelib \masm32\lib\kernel32.lib .data? hFileReadOpen HANDLE ? hCountReadByte DWORD ? ReadBufferX DWORD ? .code start: fileread macro name:req LOCAL xvalue .data xvalue db name, 0 .code invoke CreateFile, addr xvalue, GENERIC_READ, FILE_SHARE_READ,\ NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL mov hFileReadOpen, eax invoke GetFileSize, hFileReadOpen, 0 invoke ReadFile, hFileReadOpen, ADDR ReadBufferX, eax, ADDR hCountReadByte, NULL invoke CloseHandle, hFileReadOpen exitm <> endm fileread ("file1.txt") invoke MessageBox, NULL, ADDR ReadBufferX, NULL, MB_OK fileread ("file2.txt") invoke MessageBox, NULL, ADDR ReadBufferX, NULL, MB_OK fileread ("file3.txt") invoke MessageBox, NULL, ADDR ReadBufferX, NULL, MB_OK invoke ExitProcess, 0 end start
Это исправило проблему, ошибка первоначальной версии была незначительной. MSoft, Great, спасибо, проблема решена. . =) уже заметил, но дальше я попробую решить сам.
Это не исправило проблему, а лишь скрыло. Кстати, а где вообще место для буфера? Тут переполнением пахнет
Это учебный пример, а не реальная программа, созданный с целью: решить проблему повторного использования переменной. Если можно поподробнее, мысли никогда не бывают лишними. Что вы советуете использовать как наилучший вариант решения? Цель - использование одной переменной для хранения читаемой информации, с последующим обнулением после извлечения результата.
IceStudent А я бы просто читал первые 511 байт (если файл текстовый) :-P Вообще зависит от задачи. Если файл можно обрабатывать блоками, тогда я в цикле читал бы по блоку, например по 4к (удобно - размер страницы как раз) и обрабатывал. А если файл надо весь целиком сразу иметь, тогда действительно проще под весь объем динамически буфер выделить
ребята ... это конечно здорово так использовать адресное пространство ... и действительно , будет работать ... пока используешь до конца отведенной странице под данные ... потом пройдет seh и система даст сему процессу еще страниц ... гм , а могет и не дать ... случалось уже. и задавать пустые блоки в памяти процесса - тоже левая идея ... проще систему попросить выделить свободный кусок памяти. и освобождать из контекста процесса при ее ненадобности ... скока хошь. вот ... работоспособный примерчик ... там про кучу.
Geen Ты про стек? Или о резервировании памяти с подкачкой? Но здесь речь шла о неинициализированной секции данных, под неё память выделяется сразу. Если они используются всё врёмя, то смысл выделять память отдельно. А на один раз действительно проще выделить.
причем тут стек ? ... мож конечно в стеке организовать локальный буфер ... но он тож будет висеть все время. не про это речь. еще имеет смысл , когда сразу не понять - скока выделять. зри примерчик ... рабочий вроде.
А где ещё кроме стека используется подкачка, при которой ? Кроме ручной подкачки, о которой я упомянул. Как раз-таки не будет, т.к. стек по определению динамическая структура данных.
Выкладываю рабочий вариант с парой примеров, может кому пригодиться. Geen - освобождать сколько хочешь не всегда подходит под ситуацию. []
везде , где процессу не хватит памяти... он кстати этого и не заметит , как ему уже ее предоставят. и если как в первом случае , использовать только как ссылку на конец области данных (тока один дворд , типа), ему их выделят ... и так они процессу и останутся , покуда он не сгинет. и будут висеть вместе с ним... да долгую память подаренные. (пару гектар система подарить в состоянии ... расчитана на это) вот если дровина стукнет по несуществующей странице - bsod тут же. динамическая ? ... она процессу задается ... каждому - свой. и локальные буфера просто сидят выше базы стека. используется он или нет. если захочет стек побольше - то тот же вариант что и страницах с данными. их процесс не освобождает , раз поюзав. как ты думаешь , на кой системные сервисы после int 2eh выходя из контекста процесса перетаскивают данные из его стека в свой , не страничный (кроме графики , там особый случай). по приколу что ли ? ...
чет по примеру не понял необходимость ситуации... ну разве что маленькая програмка , почти не висящая долго в системе ... тогда это - фигня ... можно и гектар хапнуть.
