Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Hex Editor Neo

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7

Открыть новую тему     Написать ответ в эту тему

Altus

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Варезник » Hex Editor Neo

Hex Editor Neo
многофункциональный редактор файлов

Производитель: HHD Software | ОС: Windows 11/10/8.1/8/7/Vista/XP (x86-x64) | Интерфейс: мультиязычный (в т.ч. русский) | Размер: ~ 21 МБ

 

Официальный сайт | История изменений | Сравнение версий | Основные возможности | Страница загрузки | Версия для XP/Vista

Hex Editor Neo — профессиональный редактор шестнадцатеричных, десятичных и бинарных файлов для Windows. Программа имеет возможности по выделению, просмотру, редактированию, замене, отладке и анализу данных. Позволяет составлять пакеты в два щелчка мыши, манипулировать вашими EXE, DLL, DAT, AVI, MP3, JPG файлами с неограниченной по функцией отменой и возвратом действия. Неограниченная история изменений файла с визуализацией и возможностью её сохранения и загрузки.
  • Версия: 7.41.00.8634
  • Дата релиза: 18.12.2023
  • Скачать: hex-editor-neo.exe

  • Всего записей: 327 | Зарегистр. 06-09-2006 | Отправлено: 14:40 01-02-2013 | Исправлено: Komandor, 11:10 19-12-2023
    SevereK20

    Gold Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    del

    Всего записей: 7684 | Зарегистр. 07-05-2010 | Отправлено: 03:59 30-07-2013 | Исправлено: SevereK20, 12:30 30-07-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Хорошо, можно попробовать понять кого он зовёт. У нас есть мощный инструмент контроля - Process Hacker. Давайте посмотрим в свойствах процесса какие модули он подгружает и какие хендлы он открывает. Но, надо анализировать всё, что увидим.

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 02:38 24-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Что то портабельностью не пахнет в этой проге. Удалил папку c:\Documents and Settings\All Users\Application Data\HHD Software Hex Editor 4\ и фаил license3.hex
    И лицензия пишет неизвестна. Восстанавливаешь все путем. Подкладывание в папку программы нечего не дает. Но значит на другой комп надо и ее переносить и еще ключ в реестре, короче хоть она и говорит что установит при инсталляции портабельную версию, на самом деле обманывает.
     
    По поводу модулей вот они. Не знаю как тут сполер использовать чтоб не мозолить таким списком глаза.

      HexFrame.exe, 0x400000, 1,2 MB, HHD Software Hex Editor Neo
      advapi32.dll, 0x77dc0000, 688 kB, Расширенная библиотека API Windows 32
      ... и т.п.

    и Handles  

      Desktop, \Default, 0x28
      Directory, \KnownDlls, 0x8
      Directory, \Windows, 0x14
      Directory, \BaseNamedObjects, 0x40
      Event, \BaseNamedObjects\crypt32LogoffEvent, 0x5c
      и т.д.

     
    P.S. Если вы сравните с своим и найдется отступник, думаю можно будет отредактировать чтоб убрать сей список и оставить только виновника.
    P.P.S. пост отредактировал чтоб убрать полные списки модулей и handles не кому особо не интересных.

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 21:54 24-09-2013 | Исправлено: Jaroslave, 22:41 24-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Логи я посмотрел и вроде ничего что бы могла вызвать проблемы не вижу. Конечно возможна неисправность оборудования либо ошибка ОС, но я бы их проверил для того, чтобы исключить как возможную причину явления.

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 22:28 24-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    нет других ошибок, я был этой ошибкой сильно удивлен.
    могу тесты гонять проц греть да только нечего не изменится.
    главное что после подтверждения работает и больше не ругается, так не порядок конечно но можно и смирится.
    пост свой отредактирую убью список.
     
    Спасибо Виктор за помощь.

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 22:38 24-09-2013 | Исправлено: Jaroslave, 22:44 24-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Под море просто спрячьте - вдруг у нас какие новые идем возникнут? Сгодится. Мне и самому интересно что происходит.

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 23:27 24-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Victor_VG
    Modules под #  
    Handles под #  
     
    Выложил отсортированы по имени чтоб проще сравнивать было.
     
    Еще мысль пришла, ведь софтина ругается не на то что нет библиотеки или она не может ее загрузить, если вдуматься она пишет что не может загрузить ее в память (Cannot load GUI library into memory./это полный текст ошибки как я уже говорил),  можно предположить что у нее не удается какой то хитрый ее способ загрузки в память она предупреждает и использует стандартный способ, ведь работать то софтина работает иначе бы не смогла без гуя.
    Еще одно у меня отключен свап фаил в винде поскольку и ту что есть память проги использовать не могут, но некоторые упрямо хотят на свап что нибудь закинуть.

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 18:12 25-09-2013 | Исправлено: Jaroslave, 18:14 25-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Кстати своп можно и включить, не сильно здоровый если ОЗУ много, то 300 - 400 Мб обычно хватит, но он нужен для работы системы в целом. WinNT построена на основе DEC Open VMS а та активно работает с подкачкой.

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 00:43 26-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Victor_VG
    Знаю и включал в том числе чтоб иметь возможность дампа при  сбое, только помещал его на RAM диск. Но вот долбаный мелкософт хотя система не замусорена почему то стал, раз на раз не приходится, терять этот своп и вместо него создавать себе на диске С: своп на 3,23GB во время загрузки. Хотя на диске С: стоит запрет чего либо создавать, он на все это чихает , то видит своп на RAM то не видит. Вобщем я избавился от него полностью, тогда он самовольно негде и нечего не создает.
     
    Весь софт включая игры работает на ура и без него. Трещать хардом не намерен и тормозить из за кривости NT. Мне только одно приходит на ум что при старте служб какогото таймаута хватает еле еле и по этому раз на раз не приходится, нафиг мне такое, уж лучше вообще без него. Тем более что RAM диск используется для temp которых бывает весьма много а если там своп то он любит еще и увеличиваться в размере, NT только дай она туда все запихнет надо не надо. Памяти достаточно но она не безгранична и не эффективное ее использование не оправдано.
     

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 14:42 26-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Своп - внешняя память более медленная чем ОЗУ, но более ёмкая - архитектура ЭВМ  Дж. фон Неймана и должен располагаться вне ОЗУ, своп на RAMDisk как и он сам это бред по своей природе, посему его надо отрубить как явление.

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 16:28 26-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Victor_VG
    Вы заблуждаетесь, своп был придуман во времена нехватки оперативки, когда ее цена за мегабайт зашкаливала, а сейчас гигабайты ее некуда девать, поэтому эта технология устарела и не оправдана в использовании, кроме того использование ramdisk это попытка убрать самое узкое место в современных компах а именно скорость передачи данных с носителем, если вы посмотрите как развивалось железо то увидете что процессоры, видео, память все в тысячи раз увеличило свое быстродействие и только носители увеличили только в десятки раз его и это огромный тормоз в данный момент в компах, кроме того NT32 не может работать по лицензионным соображениям с памятью более 3,23GB а так же поскольку именно на 32 битной платформе на данный момент наибольшая совместимость с наибольшим кол-вом программного обеспечения по сравнению с 64 то остается только использовать память свыше 3,23 и не доступную NT под конкретные задачи, например ramdisk который не только продлит время службы магнитных носителей но и ускорит всю работу системы в разы. Дисковый массив особенно на маленьких файлах коими изобилуют современные ОС, софт и игры не может показать результат выше нескольких мегабайт в сек. в то время как ramdisk выдает тысячи мегабайт в сек. Как вы думаете есть разница?
     
    Кроме того создавая своп  на ramdisk вы по сути получаете возможность использовать ту область памяти которую NT не видит на прямую при этом не убивая харды и на скорости в 1000 раз быстрей любых магнитных носителей.
     
    Есть еще много разных видов использования ramdisk в том числе и клонирование томов, виртуализация, на серверах и т.д. если вы не знаете для чего может быть использован ramdisk это еще не значит что его надо отрубать

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 17:21 26-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Конечно я заблуждаюсь и не не понимаю о чём речь. Вы как я смотрю кое-что упустили, ну это сущий пустяк - всего лишь принципиальную разницу между ОЗУ и внешней памятью. Более того, я не знаю что такое NT, не знаю что такое виртуализация и клонирование томов, и вообще я ничего не знаю.  Как говоривал в своё время мой учитель Александр Максимович Ларионов - "Если вы такой грамотный, то зачем вы задаёте вопросы?".

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 18:44 26-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Victor_VG
    Только глупец может полагать что он все знает, и не задавать вопросов. Если ваш учитель не приветствовал вопросы думаю невелика его учительская ценность. А принципиальную разницу я как раз то вам и показал, видно вам просто кроме сарказма ответить нечем. Ваших аргументированных доводов не прозвучало.  
    Вы сказали что ramdisk бесполезная технология.
    Я вам возразил и доказал обратное.
    Ну а как воспринимать информацию это ваше дело, похоже вы просто не поняли сути, или не хотите ее понимать что скорей всего.
     
    P.S. Мы малость отклонились от темы, если есть желание продолжать дискуссию предлагаю в личку перейти. Или тему создать "Зачем нужны RAM -диски" и там поспорить.

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 00:50 27-09-2013 | Исправлено: Jaroslave, 01:35 27-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Согласен, более того, сам хотел продолжить разговор. Ваш стиль мышления мне нравится и вас бы в нам группу когда мы в создавали массово-параллельные вычислительные комплексы в середине 80-х. Но это сейчас не главное, а интереснее иное - а почему это решение неудачное?
     
    Давайте смотреть - каналов доступа к памяти у нас сколько? Обычно один, значит вся нагрузка I/O ляжет на него. Вот и давайте смотреть смысл того что мы имеем. А имеем мы следующее: верхняя граница физически доступного 32-х битным процессам ОЗУ определяется не лицензией, а тем, как чипсет распределит адреса I/O устройств, но т.к. для 32-х битных процессов доступно только 32 бита адреса, что и даст нам адресное пространство в 232=4 Гб на которое в архитектуре с совмещённым адресным пространством, а в ЦП х86 использована она, мы должны отобразить всё - и адреса оборудования и адреса ОЗУ. В других ЦП, к примеру nVAX, Alpha AXP, DEC F-11/J-11, AMD Am29xx, IBM 360/370, БЭСМ-6, Эльбрус-1/2 используется иная архитектура - с разделёнными адресами памяти и I/O. Вот там мы с вами можем использовать всю ёмкость ОЗУ для работы, и ограничения характерного для архитектур с общим адресным пространством мы не увидим. Да, часть адресов мы с вами выделим под системные нужды, но доступный для прикладных задач объём памяти для той же математики станет больше.  
     
    Так что с эти я думаю мы разобрались, поехали дальше. Давайте с моделью памяти разбираться. Что, зачем и что делает?
     
    Вот тут у нас и возникает иерархическая модель памяти, эдакое дерево: самый верхний уровень - быстрая память работающая на скорости АЛУ (Арифметика-Логического Устройства - именно оно непосредственно выполняет операции над данными), но т.к. данные имеют небольшой разброс адресов относительно адреса текущей машинной команды, то объём этой сверхбыстрой памяти можно сделать не столь большим - лишнее. Пошли дальше смотреть. Нам нужно расположить в памяти исполняемый код и обрабатываемые данные. Значит нужна оперативная память объёмом достаточным для их размещения, и достаточно быстрая чтобы АЛУ не простаивало в то время когда данные в СОЗУ будут обработаны, а потому мы ставим столько ОЗУ сколько нужно, а верхний предел его объёма накладывается разрядностью адресной шины ЦП. Но если небольшие задачи полностью размещаются в ОЗУ, то большие нет. Как быть? Увеличить объём ОЗУ мы конечно можем, но ведь у нас ограничена разрядность адресной шины, значит нужно искать решение. И оно есть - сегментная адресация. Принцип прост - адресное пространство делится на блоки адресуемые по двум координатам - адресу сегмента и смещению внутри него. Всё, задача решена, а управление выбором сегментов ложится на ОС, в то время как программа может использовать объём памяти больший чем ограничен шиной, но в пределах возможностей адресации ЦП как системы.  
     
    Я в 89-м решал такую задачу для 32-х битных ЦП DEC F-11/J-11 - у них 22-х битная адресная шина, а надо было адресовать не четыре, а тридцать два Мб памяти. Что делать? А у этих ЦП адресное пространство разделённое, значит можно организовать сегментную адресацию через младшие адреса шины ввода-вывода, но нужна дополнительная логика адресной дешифрации. Сделал, не проблема, и задача была решена одной ПЛМ и несколькими корпусами серии 74ABT, ну а нашим программистам пришлось попотеть привыкая к мысли о том, что память адресуется через пространство ввода/вывода. Ворчали, и крепко, но привыкли. Машинка сия после лет пятнадцать над шариком в космосе крутилась. Надо было - решили задачу.
     
    Смотрим дальше, вроде с ОЗУ разобрались, но если у нас задача выходит за его размеры как тут быть? А просто - смотрим а каким временем мы располагаем? И исходя из этого делим код на фрагменты и те, к которым нужно минимальное время доступа поместим в СОЗУ, другие в ОЗУ, а третьи, к которым мы можем увеличить время доступа вынесем в более ёмкую, но более медленную внешнюю память. Главное соблюдение условия "Основной ресурс ЭВМ это время АЛУ, и его потери нужно исключить", значит решаем задачу баланса "Потери времени АЛУ, соотношение времени доступа и скорости памяти".
     
    Вопрос - а при чём тут своп? Очень просто - это область внешней памяти в которую мы копируем те фрагменты ОЗУ которые в данный момент не используются АЛУ или данные в которых сейчас нельзя обработать, либо там код ждёт данные чтобы освободить место для того кода и данных которые сейчас нужны для АЛУ. Но, т.к. это пространство для ненужных фрагментов ОЗУ, то смысла помещать его там нет, это не увеличит производительность ЭВМ, а наоборот, снизит её производительность из-за того, что часть пропускной способности ОЗУ будет задействована на обслуживание бессмысленной перекачки фрагментов памяти.
     
    Ладно, с подкачкой понятно, с временными каталогами? Может их туда закинуть? С ними проще, там вроде интенсивность процессов ввода-вывода не велика, объекты там просто хранятся какое-то время, но к ним не нужна высокая скорость доступа, т.к. в большинстве своём это либо резервные копии, либо служебные данные ОС выполняющие роль флажков для обработчиков событий. Но ведь эти данные занимают ОЗУ, и для обращения к ним используется тот же канал памяти, но если интенсивность этих обращений не велика, то она частично нивелирует его влияние на производительность системы в целом при условии что эти данные расположены вне границ адресного пространства доступного прикладным программам, но доступ со стороны средств ОС к ним нужен, значит нужен некий инструмент трансляции адресов. Если у нас используется архитектура с разделением адресных пространств, тут всё ясно - адресацию такого логического тома можно сделать через пространство I/O, а если совмещённое адресное пространство? Что это даст? А это приведёт уже к падению производительности системы в целом поскольку мы ограничены сверху нижней границей адресного пространства портов ввода-вывода оборудования, а так же требованиями к памяти ОС и приложений, и в такой ситуации наличие задействованного под каталог для хранения временных данных (попросту системного мусора) адресного пространства приводит к необходимости вытеснения большего числа фрагментов памяти в файл подкачки скорость доступа к которому ниже, а при его отсутствии к ограничению возможности комплекса по работе с ресурсоёмкими приложениями. Но в обоих случаях производительность ЭВМ как комплекса в целом снижается.
     
    Решение об использовании части оперативной памяти в качестве электронного диска принимает пользователь, но с учётом того, что было сказано выше относительно производительности ЭВМ. А что касается показаний бенчмарков скорости чтения/записи при оценке скоростей ОЗУ и других типов памяти, то с учётом произведённого выше анализа они не объективны и показывают скорость чтения-записи ОЗУ, а главное что применяемая в них модель тестирования не совпадает с моделью работы ОС и приложений с памятью, а потому их нельзя использовать для оценки производительности комплекса т.к. эти данные дают ложную оценку быстродействия системы.

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 07:03 27-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Вы очень точно описали модель возможного использования памяти но справедливого для компьютеров порядка ~ 10 летней давности. Вся ваша модель основана на одном постулате что быстрой ОЗУ у нас критично мало.  По сути вы описали схему работы NT4-5 с памятью, но эти ОС вышли последняя XP в 2003 году. При сегодняшних скоростях и объеме, причем и каналов доступа давно как минимум 2 одновременно на чтение и запись, DDR уже давно повсеместно применяется, мы получаем возможность отойти от вашей модели и пытаться более эффективно использовать сегодняшний объем ОЗУ.
    Ограничение ОС по работе с объемом ОЗУ именно связанно с лицензированием. Я ведь не говорю что именно прямой адресации, для нее действительно 4Гб для процессора в режиме 32 предел. Но вы сами описали давно используемый прием сегментной адресации, таже EMS в DOS, и NT32bit с удовольствием работают с объемом ОЗУ в 128ГБ. Мелкософт их называет Server interprase x86 и хочет за нее совсем другие деньги, это чистый воды маркетинг, потому в обычной XP32 она удалила поддержку больших объемов памяти.  Кроме того в 32-битной NT максимальный размер файла подкачки равен 16 Тб.
    Это возможно потому что NT использует виртуальное выделение памяти, следовательно механизм для использования большего чем возможно при прямой адресации объема памяти имеется изначально.
     
    Дальше давайте рассмотрим момент когда у нас ОЗУ больше чем программа 32 битная может получить в свое управление. Виртуально ана может получить хоть 16 Tб, а вот реальной ОЗУ система больше 2 Гб или максимум 3ГБ если программа скомпилирована с флагом large_address получить не может, следовательно свободную память к которой программа в любом случае не получит доступа можно использовать для ускорения работы самой программы или системы. Создав RAMDISK и поместив на него часто используемые данные. Кроме того используя своп если он необходим приложению поскольку 2ГБ ОЗУ ее может не устроить  и она может просить больше виртуальной памяти то тут как раз может получится момент когда в свап фаил будут помешаться данные которые потребуются уже на следующем запросе данных, т.е. по сути в своп буду помещаться не редко используемые данные а из за ограничения системой в 2 ГБ в своп могут попадать текущие необходимые для расчетов данные.
    Дальше момент если своп находится на каком либо магнитном источнике то сильно скажется на быстродействие дефрагментация в нутри самого свап файла и доступ к одному сегменту виртуальной памяти может сильно замедлятся из за физ.ограничений для магнитных носителей, поскольку он будет разбит на многие фрагменты. Тут выгодно могут помочь SSD но они имеют свой недостаток, ограниченное кол-во циклов чтения-запись что при использовании их как носители свап-файла приведет к быстрому их износу.
     
    Отсюда видно что использование излишек ОЗУ в качестве RAM диска и помещении на него данных используемых для частого чтения-записи и свап-файла может значительно ускорить работу всей системы и прикладной программы в частности. Просто из опыта использования скажу что не надо проводить никаких тестов чтоб найти разницу с RAMdisk и без, потому что она видна на глаз и выражается в разах а не процентах. А так же чисто из опыта, программное обеспечение даже ресурсоемкие для крупных вычислений нагружающие систему расчетами на часы и дни обходятся 2ГБ ОЗУ и как правило не имеют флаг large_address и не просят больше виртуальной памяти. Потому свап всегда пустой не используется, точней в нем всегда 8 мегов занято системой и все, так же иногда система начинала увеличивать сам фаил свопа хотя использование его не растет, все теже системные 8 мегобайт в нем лежат. По этому я и вообще отключил при том что как я писал раньше при загрузки происходит глюк, искать причину которого мне не интересно. Для того чтобы при синем окне смерти система выполнила малый дамп памяти достаточно было держать на ramdisk свап-фаил на 32 мегабайта.
    Сам мини-дамп естественно сохранялся на системном диске являющимся обычным магнитным хардом.
     
    P.S. Исходя из нашего диалога могу сказать что ваши познания основываются на элементной базе и не удивлюсь если вы разрабатываете автоматизированные системы и разводите экспериментальные платы в P-CAD, хотя наверно сейчас уже другое программное обеспечение используется для этих целей. Мои же больше основываются на знании програмного обеспечения. У нас несколько разный подход к одним и тем же вещам.

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 20:47 27-09-2013 | Исправлено: Jaroslave, 21:06 27-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Вы знаете у нас есть одна большая разница - я инженер-системотехник по ЭВМ, системам и сетям ЭВМ, а потому мыслю не в категориях флагов компиляции под конкретную ОС, хотя мне и это хорошо знакомо, а в категориях системы в целом, и занимаюсь разработкой суперЭВМ.
     
    Что же касается вашего отрицания очевидных вещей тут всё просто - вы исходите их архитектуры IBM PC представляющей из себя классическую реализацию архитектуры фон Неймана в которой используется один общий для всех узлов канал доступа к памяти который и является узким местом системы в целом. В комплексах большой производительности где используется многоканальная архитектура памяти при которой реализуется принцип "Каждый узел имеет собственный независимый канал доступа к памяти" данное ограничение снимается, но усложняется задача управления комплексом особенно в архитектуре гиперкуб.
     
    Дальше, вы правильно указали на физические ограничения SSD как системы проистекающие из-за ограниченности физического ресурса запоминающей ячейки построенной с применением слоя подзатворного электрета (SiN) в структуре ячейки памяти - он способен в течении 10 - 15 лет сохранять наведённый электрический заряд используемый для изменения проводимости канала МОП-транзистора, но имеет ограниченное число циклов изменения состояния после которых наступает необратимая деградация его свойств, что и проявляется как отказ ячейки. Но вы неправы в утверждении что магнитные носители медлительны по природе - ваше утверждение справедливо исключительно для электро-механических устройств, но для иных типов магнитной памяти к примеру ЦМД (память на цилиндрических магнитных доменах) нет. Быстродействие ЦМД накопителей выше чем быстродействие ячейки динамического ОЗУ примерно на полтора порядка (55 - 60 нс и у ДОЗУ против 1 нс у ЦМД), но у ЦМД достаточно сложная внутренняя структура накопителя (смотрите патенты, хотя многие из них утратили силу) и высокая себестоимость производства, но у него достаточно велика удельная ёмкость - я видел экспериментальные ЦМД накопители ёмкостью в 10 Тб и размером со спичечный коробок. Правда они стоили солидно, но их изготовили в виде опытно-промышленной партии. И их быстродействие было соизмеримо с быстродействием статических микросхем памяти - длительность цикла чтение-модификация-запись ячейки 10 - 12 нс (у динамической памяти ~ 80 - 90 нс), время доступа к произвольной ячейке 15 нс, скорость случайной/последовательной записи/чтения порядка 2,7 - 2,9 Гбайт/с, длительность хранения данных при отключении источника питания порядка 700 - 730 лет, наработка на отказ порядка 7*1019 циклов перезаписи.  
     
    Так что вы и тут ошиблись, и хотя понимаете что не правы, но всё равно тащите за собой груз предубеждений. Вам надо учится и из вас выйдет не плохой инженер. В IBM и других серьёзных компаниях код пишут 18 -20 летние мальчики и девочки кодировщики, а инженеры решают гораздо более сложные задачи. Так же как работу по разводке плат в P-CAD и ему подобных пакетах выполняют не сами инженеры-конструкторы, а техники когда для них другой, более сложной работы нет, а если есть на это дело вчерашних школьников сажают - научить новичка работать с CAD можно за пару недель, а вот научить его думать и решать реальные производственные  - годы уйдут...

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 00:50 28-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Victor_VG
    Э как вы хватили. Проблема в том что от сути отклонились примерно как ушли в другую галактику. При чем тут другие архитектуры? При чем тут суперЭВМ ? При чем тут ЦМД ?
    Вообще то вопрос касался только ramdiska и только в XP 32 бит и его полезности или нет. Я оспорил только ваш совет избавиться от рамдиска не в гипотетическом суперЭВМ а в конкретном компе с которого вам пишу! И на котором выскакивает при запуске редактора информационное предупреждение.
     
    Или вы все это к тому что сами пишете с суперЭВМ а дисковым массивом у вас ЦМД и потому то вы не советуете использовать рамдис? Забыли еще сообщить какая ОС у вас в этом случае стоит.
     
    Вот ваше не обдуманное заявление.

    Цитата:
    своп на RAMDisk как и он сам это бред по своей природе

     
    Может для каких то суперЭВМ и ЦМД и неизвестных ОС это заявление окажется правдивым. Но только не для обычных домашних IBM совместимых современных компов и операционки Windows XP x86 на коих все поголовно сидят.
     
    Если вместо решения конкретной задачи углубляться в теоретические изыскания совсем не относящихся к поставленной задачи темам то решение ни когда не будет найдено даже если задача примитивная.
     
    P.S. Уточню на всякий случай везде где я писал магнитный носитель или хард я имел ввиду обычный магнитный носитель информации в простонародье называемый хард или винчестер имеющий конечный разумный объем приблизительно от 500ГБ до 2000ГБ продающийся в каждом компьютерном магазине за примерно 2,500руб. и установленный у 99% всех пользователей.

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 02:09 28-09-2013 | Исправлено: Jaroslave, 02:21 28-09-2013
    Victor_VG



    Tracker Mod
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Jaroslave
     
    Если вы убеждены что абсолютно правы, то решайте задачу сами, а у меня нет времени на убеждение вас в том, что принципы построения ЭВМ как систем не зависят от того хотите ли вы их принимать или нет.

    ----------
    Жив курилка! (Р. Ролан, "Кола Брюньон")
    Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

    Всего записей: 33133 | Зарегистр. 31-07-2002 | Отправлено: 02:16 28-09-2013
    Jaroslave

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Victor_VG
    Речи об ЭВМ тут вообще не было! От куда вы это взяли? Речи о принципах построения ЭВМ тут не было только конкретный пример использования RAMdisk в компе. Я привел ваше неверное высказывание и дал конкретное объяснение. Не можете признать своей ошибки, чтож, на это нужно мужество.
     
    А спорить о принципах построения ЭВМ я отказываюсь, потому что нечего в них не понимаю, а когда человек не понимает суть вопроса то его легко обдурить так что подтвердить или опровергнуть ваши принципы построения я не могу и не собираюсь. Ваши принципы не дают вам рассмотреть простую прикладную задачу. Иногда огромный объем знаний является лишь помехой для простого анализа несложной задачи и направляет по ложному пути. Именно по этому я в начале нашего разговора сказал что важно задавать вопросы. Я всегда и всем задаю вопросы прекрасно зная на них ответы и в 1 случае из 100 получаю интереснейшее и неожиданное решение, иногда высказанное моим собеседником иногда направившее мой ход мыслей в новом направлении.

    Всего записей: 47 | Зарегистр. 12-05-2007 | Отправлено: 02:29 28-09-2013 | Исправлено: Jaroslave, 02:45 28-09-2013
    Открыть новую тему     Написать ответ в эту тему

    Страницы: 1 2 3 4 5 6 7

    Компьютерный форум Ru.Board » Компьютеры » Программы » Hex Editor Neo


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2024

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru