Комментарии:
 |
Ох... 03.12.03 01:42
Автор: jammer <alex naumov> Статус: Elderman
|
|
не внесет ли сей ученый муж в свой списочек корову? я все чаще и чаще этого побаиваюсь.
|
| |
Ну вот оно и начинается 03.12.03 03:13
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 03.12.03 03:33 Количество правок: 2
|
> не внесет ли сей ученый муж в свой списочек корову? я все
> чаще и чаще этого побаиваюсь.
"We have had several reports from users that Norton AV 2003 is
detecting the file dnetc.com from build 483 as a Trojan. We
have confirmed this as well as confirming that Norton AV
corporate edition 8 has the same behavior."
(с)
Проблема с NAV
чешем репу?
|
|
Здравствуйте,
02.12.03 02:27
Автор: Serge3leo Статус: Незарегистрированный пользователь
|
Здравствуйте,
Всё понимаю кроме следующего предложения:
"..., но не более того. И больше всего умиляют его попытки представить себя как специалиста в области безопасности)."
Оно как-то совершенно не связанно, ни с обсуждаемой проблемой, ни с остальными частями статьи.
Или есть соображения о низком уровне профессионализма сотрудников "Лаборатории Касперского" и у них следует отозвать лицензию ГосТехКоммиссии на разработку, производство, распространение и поддержку. Или быть может ПО от "Лаборатории Каспреского" не безопасно и у них следует отозвать сертификаты ГосТехКоммиссии на те или иные продукты?
Вероятно, и продукты хорошие, и специалисты хорошие, просто рабочие моменты, связанные с совместимостью разных продуктов.
P.S.
Следует заметить, что ссылки по теме на http://www.kaspersky.ru/ не хватает.
|
| |
hi 03.12.03 01:31
Автор: jammer <alex naumov> Статус: Elderman
|
> Всё понимаю кроме следующего предложения:
> "..., но не более того. И больше всего умиляют его попытки
> представить себя как специалиста в области безопасности)."
> Оно как-то совершенно не связанно, ни с обсуждаемой
> проблемой, ни с остальными частями статьи.
Женька лапы не только к защите от вирусов, а вообще к защите как таковой тянет - это не секрет.
> Или есть соображения о низком уровне профессионализма
однозначно есть. начать с таких мелочей, как нормальный приоритет сканера по умолчанию и тормознутый монитор (на Си чтоли написан, или вообще на бейсике?). ключевые файлы - так просто курам на смех. не могу сказать что я особо много юзал касперского, но в серьезных конторах я замечаю что его сносят и ставят NAV например. повод задуматься или нет?
> сотрудников "Лаборатории Касперского" и у них следует
> отозвать лицензию ГосТехКоммиссии на разработку,
> производство, распространение и поддержку. Или быть может
> ПО от "Лаборатории Каспреского" не безопасно и у них
видимо, раз он любит корежить безобидные файлы, никак не безопасно.
> следует отозвать сертификаты ГосТехКоммиссии на те или иные
> продукты?
это не нам решать. это бизнес ;) - инвестиции, клиенты, продажи, конкуренты, налоги, отстегивания. знаю я примерно как это делается. я даже в коммерческом вузе работал 2 года, там похожий расклад, все просто.
вобщем я к тому что к делу это все не относится. сертификат о качестве софта говорит весьма мало.
> Вероятно, и продукты хорошие, и специалисты хорошие, просто
> рабочие моменты, связанные с совместимостью разных продуктов.
Женьке все прямо было сказано, ан нет, Женька уперся рогом.
честно сказать, есть у меня подозрения, что он из тех, кто любит пускать пыль в глаза лапшой на уши на тему собственной супер-пупер важности, и приводить тщательно отфильтрованный список аргументов, скрывая невыгодные. мне такой подход к делу никогда не нравился.
> Следует заметить, что ссылки по теме на
> http://www.kaspersky.ru/ не хватает.
а это, видимо, либо и так понятно, либо следует написать вебмастеру security.nnov.ru
а хватает ли ссылки писать сюда
размах!
|
| | |
Оффтоп: вопрос по поводу причин тормознутости 03.12.03 11:23
Автор: amirul <Serge> Статус: The Elderman
|
> приоритет сканера по умолчанию и тормознутый монитор (на Си
> чтоли написан, или вообще на бейсике?). ключевые файлы -
На C получаются тормозные проги или я чего то неправильно понял (насчет бейсика спорить не стану)?
|
| | | |
asm forever :| 06.12.03 07:06
Автор: jammer <alex naumov> Статус: Elderman
|
|
|
| | | | |
Одна беда - непереносим. То есть вообще нинасколько. 06.12.03 14:21
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
|
| | | | | |
"бед"-то много 24.12.03 15:08
Автор: jammer <alex naumov> Статус: Elderman
|
время на разработку, отладку и модификацию существенно больше.
непереносимость? между чем и чем (если про монитор говорим) - уточните.
только клиенты платят как раз деньги для того чтобы кривописаки в авп работали, а не писульки на сях через клипбоард копировали. лично мне графический интерфейс для монитора и засирание места в трее не нужны - а скорость работы файл-сервера куда важнее.
|
| | | | | |
Вторая беда - рефакторинг невозможен практически 08.12.03 13:07 [Ktirf, JINN]
Автор: amirul <Serge> Статус: The Elderman
|
Уже не реюз, как я писал раньше. Для того, что я имел в виду есть другое более умное слово :-)
Собственно подгонка кода под новые условия существования - БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
|
| | | | | | |
а давайте немного уйдем от девелоперских проблем. представим себе: я - юзер 24.12.03 15:23
Автор: jammer <alex naumov> Статус: Elderman
|
> Уже не реюз, как я писал раньше. Для того, что я имел в
> виду есть другое более умное слово :-)
>
> Собственно подгонка кода под новые условия существования -
> БОЛЬШАЯ проблема для асма. И на пару порядков меньшая для C
какие могут быть еще новые условия существования - обновление вирусной базы или смена сервиспака в W2k/XP ? не смеши.
если хороший хирург поможет плохому танцору - разница в размере проблемы окажется куда меньшей.
а вообще-то сабж. :) как честно заплативший. убытки от лишних тормозов можно посчитать хоть в блоках rc5, хоть в нервах юзеров в моменты сильной нагрузки. на выбор.
|
| | | | | | | |
Третья беда - полное отсутствие статической типизации 24.12.03 15:53
Автор: amirul <Serge> Статус: The Elderman
|
> какие могут быть еще новые условия существования - обновление вирусной
> базы или смена сервиспака в W2k/XP ? не смеши.
Или смена ОС или платформы. Скажи, ты дествительно не видел AVP под линух? Только не надо мне говорить про врапперы и абстрагирующий layer. Это попытка создать из асма высокоуровневую среду программирования. Это гораздо лучше сделано в том же C (хотя и тоже не без косяков).
> а вообще-то сабж. :) как честно заплативший. убытки от
> лишних тормозов можно посчитать хоть в блоках rc5, хоть в
> нервах юзеров в моменты сильной нагрузки. на выбор.
У меня уже сейчас есть несколько проектов по ~10000 строк (которые я тяну в одиночку). При этом статическая типизация ой как помогает избавиться от лишних ошибок.
Четвертая беда - чрезмерная избыточность кода, не приводящая однако к его ошибкоустойчивости. Для реализации цикла надо вводить с десяток инструкций, причем цикл так и останется неявным (инкремент-проверка-условный переход ни одно из этих явлений не говорит о непосредственно цикле). Для вызова функции - еще пара десятков. Код растет - его понимаемость снижается -> количество ошибок растет (особенно если учесть предыдущую проблему) - простой юзер недоволен (если до него вообще когда нибудь дойдет проект из хотя бы десятков-сотен тысяч строк, который принципиально пишут на асме).
У асма еще очень много бед.
Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев оптимизирующий компилятор генерирует код не хуже (а зачастую и лучше) человека. В самых крайних случаях есть inline-ассемблер. На спринте (коротких и нетривиальных кусках кода) человек еще может посоревноваться с компилятором, но на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
|
| | | | | | | | |
back to the user! 26.12.03 11:04
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 26.12.03 11:04 Количество правок: 1
|
> > какие могут быть еще новые условия существования -
> обновление вирусной
> > базы или смена сервиспака в W2k/XP ? не смеши.
> Или смена ОС или платформы.
а зачем все время сменять? есть монитор под OS1 и... скажем, OS2 ;) и под платформы. надо что-то дописать - дописывается. переносить смысла не вижу.
> Скажи, ты дествительно не видел AVP под линух?
именно. да я вообще с линуксом дел не имею и стараюсь не иметь... мне компромиссы не по душе. ;) (личная точка зрения)
> Только не надо мне говорить про врапперы и
> абстрагирующий layer. Это попытка создать из асма
> высокоуровневую среду программирования. Это гораздо лучше
> сделано в том же C (хотя и тоже не без косяков).
я и не собирался об этом говорить, я не настолько повернут на девелоперстве. слова твои понятны поодиночке, а в сочетаниях я просто даже не знаю о чем конкретно ты говоришь (только догадываюсь, вспоминая высшую школу и теорию).
> > а вообще-то сабж. :) как честно заплативший. убытки от
> > лишних тормозов можно посчитать хоть в блоках rc5, хоть в
> > нервах юзеров в моменты сильной нагрузки. на выбор.
> У меня уже сейчас есть несколько проектов по ~10000 строк
> (которые я тяну в одиночку). При этом статическая типизация
> ой как помогает избавиться от лишних ошибок.
когда во время компиляции и даже выполнения контролируются допустимые значения для переменных? да кто ж с этим поспорит, только до стандартного стародоброобучающего паскаля си все равно не дотягивает в этом контроле - во всяком случае ощущение правильности исходника у меня отсутствует. си, т.о. не изящен и нечитабелен. объявить int x и присвоить ему 'a' - ну где еще такое проканает, кроме сей. также радует и логический тип задавать целочисленным, опупенный расклад, особенно если вспомнить о разнице выполнения операций NOT, AND, OR, XOR etc над логическими и цифровыми величинами.
> Четвертая беда - чрезмерная избыточность кода, не
я думаю именно на выходе твоего компилятора получается чрезмерная избыточность кода, когда 100 байт инструкций обрамляются 100 килобайтами MFC и прочей срани.
> приводящая однако к его ошибкоустойчивости. Для реализации
> цикла надо вводить с десяток инструкций, причем цикл так и
> останется неявным (инкремент-проверка-условный переход ни
> одно из этих явлений не говорит о непосредственно цикле).
и комментариям ты тоже не обучен? ;)
> Для вызова функции - еще пара десятков. Код растет - его
а, мышление функциями, одна из убогостей сишного взгляда на программирование, в ассемблере нет функций вообще. хотя скорее тут расхождение во мнениях терминологическое, если не думать о том что скорее всего ты забываешь, что результат функции - одна величина некоторого типа, результатом процедуры может быть от нуля до множества величин.
> понимаемость снижается -> количество ошибок растет
> (особенно если учесть предыдущую проблему) - простой юзер
> недоволен (если до него вообще когда нибудь дойдет проект
> из хотя бы десятков-сотен тысяч строк, который
> принципиально пишут на асме).
кстати, про принципиальность написания я ничего не говорил. такие вещи как открытие файла или сообщение об ошибке я не вижу смысла писать на языке низкого уровня. pure asm скорее фетиш и на деле действительно - на мой взгляд - оправдывается только если приносит удовольствие автору.
> Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев
> оптимизирующий компилятор генерирует код не хуже (а
всегда хуже - как минимум из-за обрамления ненужными кусками двоичного кода в объектных и исполняемых файлах, ненужной масштабируемостью, и прочей фигней, которую даже днем с огнем всю не выключишь. я сейчас говорю на примере борландовского и мелкософтовского компилятора, про другие тонкостей не помню.
> зачастую и лучше) человека. В самых крайних случаях есть
ну если настолько неграмотен человек - место ему в вебмастерах, а не в программерах.
> inline-ассемблер.
об этом и речь. про тот же монитор можно уверенно сказать что наиболее популярные проверяющие циклы он крутит не эффективно из-за пренебрежения такой возможностью, лени, а возможно и простой неграмотности разработчиков.
> на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
в скорости и комфорте разработки, но не в результате.
типичная беда нашего времени - сделать все впопыхах. сграбить фильм с DVD, неэффективно пожать его в divx, криво перевести название на русский язык и записать его траснлитом в имя файла - утверждая что компилятор всегда побеждает. смешно.
настолько же нелепо делать гуй из монитора, которому сервисом положено было бы работать, а темы XP лепить в виде сервиса.
имхо.
PS. ну и опять же повторюсь - мы только о проблемах девелоперов рассуждаем, а проблема юзера в том что он зазря гоняет байтики в памяти по причине ленивой криворукости девелопера. я в своих попытках что-то сдевелопить поражаюсь быстродействию таких машин на которых AVP Monitor будет прорисывывать свои FUCKING иконки минут несколько при разворачивании гуевого окна. мне иконки не нужны, и регедит тоже, я бы с большим удовольвием отредактировал конфиг фаром - по образу и подобию того как я редактирую фаром конфиги freebsd.
|
| | | | | | | | | |
Есть закон неограниченности потребностей. В том плане, что... 26.12.03 14:53
Автор: amirul <Serge> Статус: The Elderman
|
> а зачем все время сменять? есть монитор под OS1 и...
> скажем, OS2 ;) и под платформы. надо что-то дописать -
> дописывается. переносить смысла не вижу.
Есть закон неограниченности потребностей. В том плане, что потребности постоянно меняются. И именно потому, что можно убить два года на проект средней крупности, а он уже будет не нужен появилось eXtreme Programming. Это не только в программировании есть. Любая система, которая пытается останвится в развитии очень быстро начинает деградировать.
> именно. да я вообще с линуксом дел не имею и стараюсь не
> иметь... мне компромиссы не по душе. ;) (личная точка
> зрения)
Ой ли. Компромиссы не по душе. А по моему обычный снобизм фрибсд-шников. :-) Я тут недавно ссылку кидал с реальными бенчмарками фри и линуха. Не в пользу BSD-систем вообще кстати (хотя фря из BSD систем действительно оказалась лучше всех)
> я и не собирался об этом говорить, я не настолько повернут
> на девелоперстве. слова твои понятны поодиночке, а в
Я тоже не повернут, между прочим. Не такие уж это и сложные понятия. Ну да ладно. :-)
> когда во время компиляции и даже выполнения контролируются
> допустимые значения для переменных? да кто ж с этим
> поспорит, только до стандартного стародоброобучающего
> паскаля си все равно не дотягивает в этом контроле - во
> всяком случае ощущение правильности исходника у меня
> отсутствует. си, т.о. не изящен и нечитабелен. объявить int
> x и присвоить ему 'a' - ну где еще такое проканает, кроме
> сей. также радует и логический тип задавать целочисленным,
> опупенный расклад, особенно если вспомнить о разнице
> выполнения операций NOT, AND, OR, XOR etc над логическими и
> цифровыми величинами.
Написал же. Что и там не без косяков, большинство из которых запросто обходятся в самом C, а в C++ уже внесены в язык.
> я думаю именно на выходе твоего компилятора получается
> чрезмерная избыточность кода, когда 100 байт инструкций
> обрамляются 100 килобайтами MFC и прочей срани.
Не обязательно линковаться с MFC, необязательно линковаться даже с рантаймом.
> и комментариям ты тоже не обучен? ;)
Ага. Комментировать каждый цикл, если это можно выразить средствами самого языка. Кстати, все более-менее сведущие программисты говорят, что этот вид комментариев - один из самых плохих. Не стоит комментировать то, что выражено в самом языке:
a = b + c; // Заносим в a сумму b и c
---
> а, мышление функциями, одна из убогостей сишного взгляда на
> программирование, в ассемблере нет функций вообще. хотя
> скорее тут расхождение во мнениях терминологическое, если
> не думать о том что скорее всего ты забываешь, что
> результат функции - одна величина некоторого типа,
> результатом процедуры может быть от нуля до множества
> величин.
Точно так же деление вызвов на процедуры и функции - одна из убогостей паскалевского взгляда на вещи. А функциональная декомпозиция - всего лишь один из шагов в ЭВОЛЮЦИИ методологии программирования. Скажу лишь, что вся эта эволюция сводится к уменьшению зависимостей между частями программы. В объектной декомпозиции связей еще меньше.
> фетиш и на деле действительно - на мой взгляд -
> оправдывается только если приносит удовольствие автору.
Вот с этим, пожалуй, соглашусь.
> всегда хуже - как минимум из-за обрамления ненужными
> кусками двоичного кода в объектных и исполняемых файлах,
Либы можно не подключать, стековые фреймы не генерировать. Тогда C просто превратится в асм. А вот асм в C не превратится никогда.
> ненужной масштабируемостью, и прочей фигней, которую даже
> днем с огнем всю не выключишь. я сейчас говорю на примере
> борландовского и мелкософтовского компилятора, про другие
> тонкостей не помню.
Не уверен, что Вы знаете тонкости борландовского и мелкософтовского компилятора, раз говорите такое.
> > зачастую и лучше) человека. В самых крайних случаях
> есть
>
> ну если настолько неграмотен человек - место ему в
> вебмастерах, а не в программерах.
Ой ли. Паровать инструкции и выравнивать по границе кеш-строки в 100000 строках ИМХО лучше это удовольствие оставить компилятору. А ведь это МИНИМУМ, который делает оптимизирующий компилятор. Мне когда то пытались привести в пример VTune, который ищет возможности для оптимизации и говорит человеку, что подправить. Вот только до сих пор не понимаю зачем в этой цепочке человек.
> > inline-ассемблер.
> об этом и речь. про тот же монитор можно уверенно сказать
> что наиболее популярные проверяющие циклы он крутит не
> эффективно из-за пренебрежения такой возможностью, лени, а
> возможно и простой неграмотности разработчиков.
А вот тут не согласен. Преждевременная оптимизация - корень всех бед. НАЧИНАТЬ ручную оптимизацию следует только после того, как программа основательно погонялась под профайлером и выявлены РЕАЛЬНЫЕ бутылочные горлышки.
> > на марафонных дистанциях (>1000 строк) компилятор
> всегда побеждает.
>
> в скорости и комфорте разработки, но не в результате.
Именно в результате.
> типичная беда нашего времени - сделать все впопыхах.
> сграбить фильм с DVD, неэффективно пожать его в divx, криво
> перевести название на русский язык и записать его
> траснлитом в имя файла - утверждая что компилятор всегда
> побеждает. смешно.
Эх. Чем-то мне эта дискуссия напоминает Urix-а. Тот тоже любил заявлять что со времен PDP ничего хорошего не придумали. И все только деградирует. Смею предположить что Вы уже весьма немолоды и как следствие боитесь новизны.
> настолько же нелепо делать гуй из монитора, которому
> сервисом положено было бы работать, а темы XP лепить в виде
> сервиса.
Не будет спорить о необходимости гуя вообще. Скажу лишь, что XP, где графическая подсистема вынесена в ядро, работает все таки быстрее чем X.
> PS. ну и опять же повторюсь - мы только о проблемах
> девелоперов рассуждаем, а проблема юзера в том что он зазря
> гоняет байтики в памяти по причине ленивой криворукости
> девелопера. я в своих попытках что-то сдевелопить поражаюсь
Ленивость и криворукость девелопера между прочим никак не относится к удобству среды разработки. Можно даже сказать наоборот: чем удобнее работается девелоперу, тем лучше будет юзеру в конце концов.
> тоже, я бы с большим удовольвием отредактировал конфиг
> фаром - по образу и подобию того как я редактирую фаром
> конфиги freebsd.
Поздравляю. Во первых не забывайте о позиционировании. Во вторых вспомните, сколько всего вынесено в реестр (опять таки не станем спорить зачем столько настроек) и подумайте с какой скоростью выполнялся бы поиск по текстовой базе. Реестр - это база данных. А БД для эффективной работы просто обязана быть бинарной.
|
| | | | | | | | | |
проблемы девелоперов быстро превращаются в проблемы юзеров 26.12.03 13:23
Автор: dl <Dmitry Leonov>
|
|
Раз и навсегда написанные программы - это идеальный случай. Меняются условия, меняются требования, программу нужно обновлять, причесывать, поддерживать. Самый идеальный код на ассемблере начиная с какого-то уровня сложности проекта развалится точно так же, как кривая поделка на васике или дельфи, и исправить в нем что-то станет просто нереально.
|
| | | | | | | | | | |
или начиная с NT4 ничего не меняется - или я что-то пропустил? 26.12.03 13:45
Автор: jammer <alex naumov> Статус: Elderman
|
|
это на тему монитора.
|
| | | | | | | | | | | |
NT, Linux и многое прочее на С написано 26.12.03 13:59
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 26.12.03 14:06 Количество правок: 1
|
|
Есть конечно фрагменты на асме, но в основном - С. Единственная ОС писанная на чистом асме которую я знаю - Menuet OS. Причем я бы не сказал что она очень шустрая (для своих размеров) да и существует она тока для х86. Что касается скорости асма - во первых никто тебя не вынуждает использовать тот же MFC или даже вообще пользоваться стандартными функциями С. Во вторых трудновато тебе будет держать в памяти тайминги всех инструкций, расставлять их так чтобы они работали максимально быстро на современных процессорах с ихним кэшированием и предсказанием переходов. Этим как раз прекрасно занимается компилятор тогоже С.
|
| | | | | | | | | | | | |
наверное даже компилятор С написан на С? ваау. это прямо таки pkunzip.zip! ;) 26.12.03 15:10
Автор: jammer <alex naumov> Статус: Elderman
|
> Есть конечно фрагменты на асме, но в основном - С.
я блин про "фрагменты" и говорил. полсекунды или секунду будет выполняться подпрограмма, которая выполняется раз в сутки, меня абсолютно not a bird. просьба: читать если меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не фантазировать, не подставлять свой субъективный контекст - вы заведомо ошибетесь и сознательно меня не поймете.
> касается скорости асма - во первых никто тебя не вынуждает
> использовать тот же MFC или даже вообще пользоваться
> стандартными функциями С.
да вообще этим нечитабельным языком, только в котором и возможны ляпсусы типа (см. ссылку ниже).
> Во вторых трудновато тебе будет
> держать в памяти тайминги всех инструкций, расставлять их
> так чтобы они работали максимально быстро на современных
> процессорах с ихним кэшированием и предсказанием переходов.
> Этим как раз прекрасно занимается компилятор тогоже С.
в памяти нет смысла держать. занимается не настолько прекрасно как тебе кажется, и простое дизассемблирование тебя в этом легко убедит. напиши int x = 10 и собери екзешник, вместо 10 байт у тебя получится 100К.
указанный Ktirf-ом глюк
|
| | | | | | | | | | | | | |
Ты прав, GCC написан на С :) 26.12.03 15:37
Автор: Killer{R} <Dmitry> Статус: Elderman
|
> > Есть конечно фрагменты на асме, но в основном - С.
> я блин про "фрагменты" и говорил. полсекунды или секунду
> будет выполняться подпрограмма, которая выполняется раз в
> сутки, меня абсолютно not a bird. просьба: читать если
> меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не
> фантазировать, не подставлять свой субъективный контекст -
> вы заведомо ошибетесь и сознательно меня не поймете.
На асме в основном делаются фрагменты работающие с железом напрямую. Ввод вывод в порты имхо на асме делать просто легче. А насчет скорости - расскажу легенду которую мне самому как то рассказывали. Был один чел у нас который весьме нехило шарил в асме. И решил он написать небольшую программку (с циклом, считала чтото) с целью обойти в скорости аналогичный код на С скомпиленный в Watcom C. Чел обломался.
> > касается скорости асма - во первых никто тебя не
> вынуждает
> > использовать тот же MFC или даже вообще пользоваться
> > стандартными функциями С.
>
> > Во вторых трудновато тебе будет
> > держать в памяти тайминги всех инструкций, расставлять
> их
> > так чтобы они работали максимально быстро на
> современных
> > процессорах с ихним кэшированием и предсказанием
> переходов.
> > Этим как раз прекрасно занимается компилятор тогоже С.
>
> в памяти нет смысла держать. занимается не настолько
> прекрасно как тебе кажется, и простое дизассемблирование
> тебя в этом легко убедит. напиши int x = 10 и собери
> екзешник, вместо 10 байт у тебя получится 100К.
Получится порядка 1 кб. Тут недавно пролетала мессага о том как отключить стандартные Сшные либы в которых содержатся такие стандартные функции как printf, malloc, и прочее. А 1кб - это изза PE заголовка. 10байтный PE ехешник ты никак не сможешь сделать. Кстати ничего страшного даже в том что в ехешнике лежит код который и выполняться то никогда не будет. Механизм запуска приложений в виндах таков, что если участок кода не юзается то он не будет никогда загружен в память.
> да вообще этим нечитабельным языком, только в котором и
> возможны ляпсусы типа (см. ссылку ниже).
В асме таких ляпусов может быть намноого больше. xor eax,eax вместо mov eax,edx в коде состоящем и гораздо большего количества строк мог бы привести к примерно такому же эффекту.
|
| | | | | | | | | | | | | |
Ага. И это называется раскрутка компилятора. 26.12.03 15:31
Автор: amirul <Serge> Статус: The Elderman
|
Первая версия пишется на чем угодно (хоть на бейсике). Собирается компилятор. Все следующие версии компилятора пишутся на нем самом. И VC, и gcc.
> я блин про "фрагменты" и говорил. полсекунды или секунду
> будет выполняться подпрограмма, которая выполняется раз в
> сутки, меня абсолютно not a bird. просьба: читать если
> меня, то ВНИМАТЕЛЬНО и ничего НЕ ДОДУМЫВАТЬ и не
> фантазировать, не подставлять свой субъективный контекст -
> вы заведомо ошибетесь и сознательно меня не поймете.
Гы. Ну знамо дело. Все в го*не один ты д'Артаньян. "вы заведомо ошибаетесь" вот это вот как раз и есть подстановка к нам своего субъективного контекста.
> > касается скорости асма - во первых никто тебя не
> вынуждает
> > использовать тот же MFC или даже вообще пользоваться
> > стандартными функциями С.
>
> да вообще этим нечитабельным языком, только в котором и
> возможны ляпсусы типа (см. ссылку ниже).
Да уж. В асме таких ляпсусов не бывает. Там просто можно побочноый эффект изменения какого нибудь флага использовать. Или я видел прикол (еще под досом): в кеш загружалась строка, в которой есть одно обращение к памяти и один безусловный переход. Причем обращение к памяти - это запись адреса перехода следующей инструкции. Но так как инструкция уже в кеше (или даже прошла пол-конвейера), переход осуществлялся по старому адресу. А отладчики всегда уходили по новому.
Не надо говорить, что инструмент плохой, только потому, что вы не умеете им пользоваться. После некоторого опыта работы (не сильно большого к слову), программист уже никогда случайно не напишет вместо сравнения присвоение.
Чтобы не переливать из пустого в порожнее, давайте я вам попросим кого нибудь написать реализацию какого-нибудь нетривиального алгоритма на C и на асме (можно даже откомпилировать исходную программу в асм). И дать без комментариев разным людям. Вы действительно уверены, что человек, которому попадется асм без комментариев столкнется с меньшими проблемами при чтении, чем С-шник. Если да, то мне просто не о чем с Вами больше говорить. Таких людей не прошибешь НИКАКИМИ аргументами. Тут уже был такой, который обвинял меня в ошибках (по его мнению) в СТАНДАРТЕ C++.
> > Во вторых трудновато тебе будет
> > держать в памяти тайминги всех инструкций, расставлять
> их
> > так чтобы они работали максимально быстро на
> современных
> > процессорах с ихним кэшированием и предсказанием
> переходов.
> > Этим как раз прекрасно занимается компилятор тогоже С.
>
> в памяти нет смысла держать. занимается не настолько
> прекрасно как тебе кажется, и простое дизассемблирование
> тебя в этом легко убедит. напиши int x = 10 и собери
> екзешник, вместо 10 байт у тебя получится 100К.
Да? А может поспорим, что я могу написать на C программу, которая будет занимать минимальный для данного формата объем? А может заглянете в раздел FAQ? Вещи-то довольно простые и я удивлен, что Вы их не знаете.
ЗЫ: Кстати, программа из int x = 10 не будет занимать вообще ничего, т.к. компилятор соптимизирует неиспользуемую переменную. Если же написать volatile int x = 10, то программа не будет содержать ни одной ИСПОЛНЯЕМОЙ инструкции - только сегмент данных, в котором будет содержаться переменная x, проинициализированная значением 10.
|
| | | | | | | | | | | | | | |
нет ничего более постоянного, чем временное 03.01.04 04:35
Автор: jammer <alex naumov> Статус: Elderman
|
> Первая версия пишется на чем угодно (хоть на бейсике).
сабж.
> > вы заведомо ошибетесь и сознательно меня не поймете.
> Гы. Ну знамо дело. Все в го*не один ты д'Артаньян. "вы
> заведомо ошибаетесь" вот это вот как раз и есть подстановка
> к нам своего субъективного контекста.
это мимо тазика - смотри коммент от LLL
> > вынуждает
> > > использовать тот же MFC или даже вообще
> пользоваться
> > > стандартными функциями С.
> > да вообще этим нечитабельным языком, только в котором
> Да уж. В асме таких ляпсусов не бывает. Там просто можно
мимо тазика2 - асм не задумывался как ЯВУ
> побочноый эффект изменения какого нибудь флага
можно и нужно, иначе недалеко от уйдешь от твоего горе-оптимизирующего компилятора.
> Не надо говорить, что инструмент плохой, только потому, что
> вы не умеете им пользоваться. После некоторого опыта работы
> (не сильно большого к слову), программист уже никогда
> случайно не напишет вместо сравнения присвоение.
даже клавиатуры глотают буквы, что уж говорить о злоумышленниках. так что если язык дыряв генетически и не дает шансов легко заметить ошибку, не делая синтаксического анализа на нескольких листах А4 карандашом, тут вообще шансов мало.
> Чтобы не переливать из пустого в порожнее, давайте я вам
> попросим кого нибудь написать реализацию какого-нибудь
> нетривиального алгоритма на C и на асме (можно даже
> откомпилировать исходную программу в асм). И дать без
будьте добры. вполне достаточно относительно тривиальный алгоритм, без FPU и API. выложить исходник на С, промежуточный асм и результирующий .exe (лучше .com, дабы заголовки не мешали считать)
> комментариев разным людям. Вы действительно уверены, что
> человек, которому попадется асм без комментариев столкнется
> с меньшими проблемами при чтении, чем С-шник. Если да, то
нет. зато в отличие от "С-шника" тут нет попытки и сесть на возлюбленный орган, и успеть еще покушать при этом (перефразируя слегка ;)
> > в памяти нет смысла держать. занимается не настолько
> > прекрасно как тебе кажется, и простое
> дизассемблирование
> > тебя в этом легко убедит. напиши int x = 10 и собери
> > екзешник, вместо 10 байт у тебя получится 100К.
> Да? А может поспорим, что я могу написать на C программу,
> которая будет занимать минимальный для данного формата
> объем? А может заглянете в раздел FAQ? Вещи-то довольно
> простые и я удивлен, что Вы их не знаете.
ты про http://www.bugtraq.ru/forum/faq/programming/small*.html ? видел, видел. результат хороший не значит лучший.
> ЗЫ: Кстати, программа из int x = 10 не будет занимать
> вообще ничего, т.к. компилятор соптимизирует неиспользуемую
> переменную. Если же написать volatile int x = 10, то
> программа не будет содержать ни одной ИСПОЛНЯЕМОЙ
> инструкции - только сегмент данных, в котором будет
> содержаться переменная x, проинициализированная значением
> 10.
не крути хвостом... ты меня прекрасно понял.
|
| | | | | | | | | | | | | | | |
Скажи честно, ты когда нибудь видел программу >=10000 строк? 04.01.04 08:28
Автор: amirul <Serge> Статус: The Elderman
|
|
|
| | | | | | | | | | | | | | | | |
да я вообще не девелопер - см. анкету. так, дизассемблировал разве чего в юности от скуки. 06.01.04 04:24
Автор: jammer <alex naumov> Статус: Elderman
|
|
|
| | | | | | | | | | | | | | | | | |
Почал админ девелоперов учить... :-/ 06.01.04 12:04
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
Я думаю, стоит остановиться. Сиди на своем асме, и пиши "критичные участки кода, где компилятор лажается". А мы уж как-нибудь так, по-простому.
|
| | | | | | | | | | | | | | | | | | |
Я еще в треде про RTFM написал 06.01.04 13:28
Автор: amirul <Serge> Статус: The Elderman
|
> Я думаю, стоит остановиться. Сиди на своем асме, и пиши
> "критичные участки кода, где компилятор лажается". А мы уж
> как-нибудь так, по-простому.
Что это очередная инкарнация Urix-а, и спорить бесполезно. На любые аргументы следует или прыжок в сторону или аргументация на уровне "сам дурак". Только тот тред был глючный (небось на яву писанный, а не на асме :-) ) и мой пост канул в лету :-)
|
| | | | | | | | | | | | | | | | | | | |
Не накручивай. Просто закроем и все. Можно перенести с какого-нибудь места в misc и там закрыть. 06.01.04 15:45
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 06.01.04 15:46 Количество правок: 1
|
|
Например, начиная с твоего "Оффтопа" - вполне символично :)
|
| | | | | | | | | | | | | | | | | | | | |
Не переносится :-( 06.01.04 18:31
Автор: amirul <Serge> Статус: The Elderman
|
> Например, начиная с твоего "Оффтопа" - вполне символично :)
И не закрывается.
Тогда поступлю по другому - перестаю отвечать в данном треде, кто бы что ни говорил. Чего и другим желаю. Авось само уляжется :-)
|
| | | | | | | | | | | | | | | | | | | | | |
"Вторая беда" переносится 06.01.04 19:23
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
|
| | | | | | | | | | | | | | | |
вот смотрю я на свой проект в 20000 строчек на С++... 03.01.04 07:38
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 03.01.04 07:58 Количество правок: 2
|
> > Да уж. В асме таких ляпсусов не бывает. Там просто
> можно
> мимо тазика2 - асм не задумывался как ЯВУ
Ошибка - это удел человека а не компилятора. И высокого тот уровня низкого или вообще машинные коды - ошибки делают люди.
> будьте добры. вполне достаточно относительно тривиальный
> алгоритм, без FPU и API. выложить исходник на С,
> промежуточный асм и результирующий .exe
Гы. Как раз современные программах больше всего нетривиальных алгоритмов. Кстати тривиальный алгоритм - разделить число на 10. Как вы его реализуете на асме? (если знаете этот фокус то хорошо, но ведь таких фокусов ОЙ как много, причем намного менее очевидных, причем на разных аппаратных платформах, даже с разными процессорами фокусы разные, имхо под интеловские процессоры лучше всего код генерит Intel CPP compiler)
>(лучше .com, дабы
> заголовки не мешали считать)
Ах так вы еще вспоминаете DOS'овские программы, и вероятно соответствующие компиляторы имеете ввиду.. Рассчитанные под 8086. А между тем современные программы это не десяток-сотня строчек считающих там чтото а десятки и сотни тысяч строк кода различных модулей на С которые между прочим очень взаимосвязаны. Вы писали когда нибудь проект больше 5000 строчек на С? И как у вас было сильное желание переписать все это на асме чтобы оно работало надежнее и быстрее? Учитывая что последовательные обращения к областям памяти лучше делать через инструкции необращаюиеся к памяти. А еще непомешало бы посчитать время выполнения каждой инструкции и собрать их стока чтоб за время их выполнения как раз прошел тик генератора тактовой частоты системной шины чтоб были минимальны задержки при очередном обращении к памяти. Что обращения по возможноти надо делать так чтобы они влезали в кэш. А если чтото не влезает то лучше бы его отнести в другое время. + еще учтите многозадачную архитектуру современных ОС когда несколько участков кода могут работать одновременно, и ежели мы пишем крупный проект который может работать на сервере то не мешало бы его оптимизировать под многопроцессорные архитектуры что тоже знаетеле не просто так и может дать выигрыш от совсем никакого до почти двухкратного. Компилятор это все знает, и считатет тайминги намного быстрее человека. Я говорю не про Borland CPP 5.01.
> нет. зато в отличие от "С-шника" тут нет попытки и сесть на
> возлюбленный орган, и успеть еще покушать при этом
> (перефразируя слегка ;)
Так вот касательно моего проекта на 20000 строчек на С++. Он работает. Вполне реально. И имхо он проще антивиря касперского хотя антивирей я не писал. А вот ежели это все переписать на асме... И положим отладить до приемлемого уровня.. Боюсь там не то что в 3 раза будет больше кода а в 10. Во первых я за это время на него попросту забью пока чтото там заработает, во вторых даже если не забью и не помру от старости очень врядли что мне удастся сделать код более эффективный чем это делает компилятор.
И возвращаясь к топику. Вам бы хотелось каждый раз перекачивать весь антивирь касперского после каждого обновления? Еслиб все процедуры обнаружения вирей были писаны на асме имхо так бы оно и было. + гораздо более высокая стоимость продукта. + очень я сомневаюсь что он был бы стабильнее. Конечно можно говорить что АСМ "не ЯВУ", но идеальных программистов не бывает, тот кто длает ошибки в С сделает их гораздо больше на АСМе. Любой компилятор в этом смысле гораздло идеальнее перегоняет большое количество кода в машинные коды нежели человек сразу это все вдруг вздумает написать.
Напоследок пару листингов кину - одной маааленькой функции экспортируемой DLL'ой того проекта и ее АСМовый листинг (скомпилено на VC6.0):
DWORD __stdcall NVGetMetaVarA(DWORD HostID, char *VarName, char *DataBuff, DWORD *BuffSize)
{
if(!TestIPCWND())return 0;
DWORD sz=*BuffSize+sizeof(NV_IPC_DATA)+sizeof(NVMETAVAR);
NV_IPC_DATA *nvipc=(NV_IPC_DATA *)HeapAlloc(hip,0,sz);
nvipc->size=sz;
strcpy(nvipc->ipcID,"NetView_IPC_structure_Killer{R}");
nvipc->msg=NMPN_METAVAR;
nvipc->wp=NVMETAVAR_GET|NVMETAVAR_USEID;
nvipc->datalen=*BuffSize+sizeof(NVMETAVAR);
strcpy(((NVMETAVAR *)nvipc->data)->varname,VarName);
((NVMETAVAR *)nvipc->data)->host.id=HostID;
((NVMETAVAR *)nvipc->data)->vallen=*BuffSize;
DWORD ret=SendMessage(nvwnd,NMPN_NVIPC,GetCurrentProcessId(),(DWORD)nvipc);
sz=((NVMETAVAR *)nvipc->data)->vallen;
if(sz>*BuffSize)sz=*BuffSize;
if(sz)CopyMemory(DataBuff,((NVMETAVAR *)nvipc->data)->val,sz);
*BuffSize=((NVMETAVAR *)nvipc->data)->vallen;
HeapFree(hip,0,nvipc);
return ret;
}
Асм:
Exported fn(): NVGetMetaVarA - Ord:000Ah
Exported fn(): _NVGetMetaVarA@16 - Ord:001Ah
:10001770 E8ABF9FFFF call 10001120
:10001775 84C0 test al, al
:10001777 7505 jne 1000177E
:10001779 33C0 xor eax, eax
:1000177B C21000 ret 0010
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:10001777(C)
:1000177E 53 push ebx
:1000177F 55 push ebp
:10001780 8B6C2418 mov ebp, dword ptr [esp+18]
:10001784 A1D0200010 mov eax, dword ptr [100020D0]
:10001789 56 push esi
:1000178A 57 push edi
:1000178B 8B7500 mov esi, dword ptr [ebp+00]
:1000178E 81C6F8000000 add esi, 000000F8
:10001794 56 push esi
:10001795 6A00 push 00000000
:10001797 50 push eax
* Reference To: KERNEL32.HeapAlloc, Ord:0199h
|
:10001798 FF1504100010 Call dword ptr [10001004]
:1000179E 8BD8 mov ebx, eax
* Possible StringData Ref from Code Obj ->"NetView_IPC_structure_Killer{R}"
|
:100017A0 BF78100010 mov edi, 10001078
:100017A5 83C9FF or ecx, FFFFFFFF
:100017A8 33C0 xor eax, eax
:100017AA 8933 mov dword ptr [ebx], esi
:100017AC 8D5304 lea edx, dword ptr [ebx+04]
:100017AF F2 repnz
:100017B0 AE scasb
:100017B1 F7D1 not ecx
:100017B3 2BF9 sub edi, ecx
:100017B5 53 push ebx
:100017B6 8BC1 mov eax, ecx
:100017B8 8BF7 mov esi, edi
:100017BA 8BFA mov edi, edx
:100017BC 8D93B4000000 lea edx, dword ptr [ebx+000000B4]
:100017C2 C1E902 shr ecx, 02
:100017C5 F3 repz
:100017C6 A5 movsd
:100017C7 8BC8 mov ecx, eax
:100017C9 33C0 xor eax, eax
:100017CB 83E103 and ecx, 00000003
:100017CE F3 repz
:100017CF A4 movsb
:100017D0 8B7C241C mov edi, dword ptr [esp+1C]
:100017D4 C7432402080000 mov [ebx+24], 00000802
:100017DB C7432802000000 mov [ebx+28], 00000002
:100017E2 8B4D00 mov ecx, dword ptr [ebp+00]
:100017E5 81C1C4000000 add ecx, 000000C4
:100017EB 894B30 mov dword ptr [ebx+30], ecx
:100017EE 83C9FF or ecx, FFFFFFFF
:100017F1 F2 repnz
:100017F2 AE scasb
:100017F3 F7D1 not ecx
:100017F5 2BF9 sub edi, ecx
:100017F7 8BC1 mov eax, ecx
:100017F9 8BF7 mov esi, edi
:100017FB 8BFA mov edi, edx
:100017FD C1E902 shr ecx, 02
:10001800 F3 repz
:10001801 A5 movsd
:10001802 8BC8 mov ecx, eax
:10001804 83E103 and ecx, 00000003
:10001807 F3 repz
:10001808 A4 movsb
:10001809 8B4C2418 mov ecx, dword ptr [esp+18]
:1000180D 894B34 mov dword ptr [ebx+34], ecx
:10001810 8B5500 mov edx, dword ptr [ebp+00]
:10001813 8993F4000000 mov dword ptr [ebx+000000F4], edx
* Reference To: KERNEL32.GetCurrentProcessId, Ord:00F8h
|
:10001819 FF150C100010 Call dword ptr [1000100C]
:1000181F 50 push eax
:10001820 A1D4200010 mov eax, dword ptr [100020D4]
:10001825 689A050000 push 0000059A
:1000182A 50 push eax
* Reference To: USER32.SendMessageA, Ord:0214h
|
:1000182B FF1548100010 Call dword ptr [10001048]
:10001831 8B8BF4000000 mov ecx, dword ptr [ebx+000000F4]
:10001837 89442420 mov dword ptr [esp+20], eax
:1000183B 8B4500 mov eax, dword ptr [ebp+00]
:1000183E 3BC8 cmp ecx, eax
:10001840 7602 jbe 10001844
:10001842 8BC8 mov ecx, eax
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:10001840(C)
:10001844 85C9 test ecx, ecx
:10001846 7418 je 10001860
:10001848 8B7C241C mov edi, dword ptr [esp+1C]
:1000184C 8BD1 mov edx, ecx
:1000184E 8DB3F8000000 lea esi, dword ptr [ebx+000000F8]
:10001854 C1E902 shr ecx, 02
:10001857 F3 repz
:10001858 A5 movsd
:10001859 8BCA mov ecx, edx
:1000185B 83E103 and ecx, 00000003
:1000185E F3 repz
:1000185F A4 movsb
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:10001846(C)
:10001860 8B83F4000000 mov eax, dword ptr [ebx+000000F4]
:10001866 53 push ebx
:10001867 894500 mov dword ptr [ebp+00], eax
:1000186A 8B0DD0200010 mov ecx, dword ptr [100020D0]
:10001870 6A00 push 00000000
:10001872 51 push ecx
* Reference To: KERNEL32.HeapFree, Ord:019Fh
|
:10001873 FF1514100010 Call dword ptr [10001014]
:10001879 5F pop edi
:1000187A 5E pop esi
:1000187B 8B442418 mov eax, dword ptr [esp+18]
:1000187F 5D pop ebp
:10001880 5B pop ebx
:10001881 C21000 ret 0010
Замечу что функция простая и ничего "выкрутасного" для компилятора не делает. (Выкрутасы - это раскрутка циклов, оптимизация переменных и много чего еще)
|
| | | | | | | | | | | | | | | | |
согласись, сложно ошибиться в команде repz, и даже в and... 06.01.04 04:54 Штраф: 40 [HandleX, amirul]
Автор: jammer <alex naumov> Статус: Elderman
|
> > > Да уж. В асме таких ляпсусов не бывает. Там
> > мимо тазика2 - асм не задумывался как ЯВУ
> Ошибка - это удел человека а не компилятора. И высокого тот
> уровня низкого или вообще машинные коды - ошибки делают
> люди.
согласись, сложно ошибиться в команде repz, и даже в and ecx, 00000003 (цитирую твой же код). асм изначально рассчитан на другой уровень аккуратности, чем ЯВУ. так что и ошибки в нем другие.
> Гы. Как раз современные программах больше всего
> нетривиальных алгоритмов.
а нетривиальный алгоритм раскладывается на тривиальные части.
> Кстати тривиальный алгоритм -
> разделить число на 10. Как вы его реализуете на асме? (если
> знаете этот фокус то хорошо, но ведь таких фокусов ОЙ как
> много, причем намного менее очевидных, причем на разных
> аппаратных платформах, даже с разными процессорами фокусы
> разные, имхо под интеловские процессоры лучше всего код
> генерит Intel CPP compiler)
да не нравятся мне интеловские процессоры :) тормозят.
> Ах так вы еще вспоминаете DOS'овские программы, и вероятно
> соответствующие компиляторы имеете ввиду.. Рассчитанные под
> 8086. А между тем современные программы это не
> десяток-сотня строчек считающих там чтото а десятки и сотни
> тысяч строк кода различных модулей на С которые между
> прочим очень взаимосвязаны. Вы писали когда нибудь проект
нет смысла повторять идентичный вопрос. нет. это последний ответ об этом.
> больше 5000 строчек на С? И как у вас было сильное желание
> переписать все это на асме чтобы оно работало надежнее и
> быстрее? Учитывая что последовательные обращения к областям
> памяти лучше делать через инструкции необращаюиеся к
> памяти. А еще непомешало бы посчитать время выполнения
> каждой инструкции и собрать их стока чтоб за время их
> выполнения как раз прошел тик генератора тактовой частоты
> системной шины чтоб были минимальны задержки при очередном
> обращении к памяти. Что обращения по возможноти надо делать
> так чтобы они влезали в кэш. А если чтото не влезает то
> лучше бы его отнести в другое время. + еще учтите
> многозадачную архитектуру современных ОС когда несколько
> участков кода могут работать одновременно, и ежели мы пишем
> крупный проект который может работать на сервере то не
> мешало бы его оптимизировать под многопроцессорные
> архитектуры что тоже знаетеле не просто так и может дать
> выигрыш от совсем никакого до почти двухкратного.
> Компилятор это все знает, и считатет тайминги намного
> быстрее человека. Я говорю не про Borland CPP 5.01.
не стану с этим спорить, но это не отменяет пользы от ручной оптимизации на уровне асма (или изначального написания на асме) некоторых критических участков, где компилятор лажается. особенно если учесть что один и тот же екзешник, оптимизированный под интел, будет работать на АМД гадко, и наоборот. для развития мысли можно применить твой аргумент о том, что платформ множество - более двух.
> Так вот касательно моего проекта на 20000 строчек на С++.
> Он работает. Вполне реально. И имхо он проще антивиря
> касперского хотя антивирей я не писал. А вот ежели это все
> переписать на асме... И положим отладить до приемлемого
> уровня.. Боюсь там не то что в 3 раза будет больше кода а в
> 10. Во первых я за это время на него попросту забью пока
> чтото там заработает, во вторых даже если не забью и не
> помру от старости очень врядли что мне удастся сделать код
> более эффективный чем это делает компилятор.
это все проблемы девелоперов, и не играет роли.
> И возвращаясь к топику. Вам бы хотелось каждый раз
> перекачивать весь антивирь касперского после каждого
> обновления? Еслиб все процедуры обнаружения вирей были
> писаны на асме имхо так бы оно и было. + гораздо более
не вижу связи. обновление иполняемых бинарников и так идет не кусками файлов, а целиковыми файлами, причем большими целиковыми файлами, содержащими немаленькую кучу рожденного компилятором мусора. да что мешало бы обновлять это по частям при изменении языка исходника?
> сделает их гораздо больше на АСМе. Любой компилятор в этом
> смысле гораздло идеальнее перегоняет большое количество
> кода в машинные коды нежели человек сразу это все вдруг
> вздумает написать.
я не сравнивал машину и человека в процессе "перегоняния" (какие у тебя самогонные термины, однако :) вМАШИННЫЕ_КОДЫ так что попрошу не передергивать.
> Напоследок пару листингов кину - одной маааленькой функции
> экспортируемой DLL'ой того проекта и ее АСМовый листинг
и ты конечно же хочешь сказать что тут лишнего почти нет? :)
удачи.
|
| | | | | | | | | | | | | | | | | |
Задрал... Штраф за флейм! 06.01.04 06:49
Автор: HandleX <Александр М.> Статус: The Elderman
|
Что против прогресса-то идти?
Вот ты тут с пеной у рта доказываешь, что стетоскоп лучше томографа... Для каждого инструмента — своё применение... Что со стетоскопом хороший доктор совершит меньше ошибок, чем другой доктор, используя томограф...
Ассемблер появился с самого начала. Для того, чтобы упростить программирование в машинных кодах. И он реально нужен до сих пор, никто не спорит... Но только там, где он реально нужен ;-)
|
| | | | | | | | | | | | | | |
поправочка 30.12.03 19:38
Автор: LLL <Алексей> Статус: Member
|
> > вы заведомо ошибетесь и сознательно меня не поймете.
> Гы. Ну знамо дело. Все в го*не один ты д'Артаньян. "вы
> заведомо ошибаетесь" вот это вот как раз и есть подстановка
> к нам своего субъективного контекста.
там было "ошиБЕТесь", а не "ошиБАЕТесть"
не зря товарищ рекомендует читать его внимательнее ;-)
|
| | | | | | | | | | | | | | | |
А время в данном случае не важно 04.01.04 08:20
Автор: amirul <Serge> Статус: The Elderman
|
> > > вы заведомо ошибетесь и сознательно меня не
> поймете.
> > Гы. Ну знамо дело. Все в го*не один ты д'Артаньян. "вы
> > заведомо ошибаетесь" вот это вот как раз и есть
> подстановка
> > к нам своего субъективного контекста.
>
> там было "ошиБЕТесь", а не "ошиБАЕТесть"
> не зря товарищ рекомендует читать его внимательнее ;-)
Говорить, что человек ошибется или ошибается априори - значит просто отказывать ему в способности судить. Но даже не это главное. Главное - себе способность судить оставляется. А ошибетесь или ошибаетесь - не суть. Но это уже флуд.
|
| | | | | | | | |
Однако приятнее 25.12.03 19:03
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
|
|
|
Как proxy стал злобным вирусом 28.11.03 13:55
Автор: VEK Статус: Незарегистрированный пользователь
|
|
Да... Как-то и раньше не очень доверял AVP, по-этому в свое время стал пользоваться DrWeb' ом. Представьте, что скоро Microsoft выйдет на рынок антивирусов, боюсь, тогда весь open-source софт в вирусы и трояны запишут :)
|
|
на сколько я помню WinGate тоже определялся как троян... 28.11.03 12:24
Автор: DamNet <Denis Amelin> Статус: Elderman
Отредактировано 28.11.03 12:26 Количество правок: 1
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
