Здравствуйте, Cyberax, Вы писали:

C>thunk — это не команда, а ассемблерный трюк. Он заключается в том, что
C>вместо указателя на целевую функцию используется указатель на
C>динамически сгенерированный блок кода.

Ну, и не надо тогда говорить про недостатки виртуальных машин. Твои thunk-и на фиг не упали для реализации нужной функциональности. То же самое можно реализовать на базе функциональных объетктов, генерации кода и кучи других вещей.

Хаскель медленен алгоритмически. И с этим ничего не поделаешь. В остальном противопоказаний для реализации его на VM нет. Конечно если бы были некторые конструкции, то работу можно было бы упростить, но не более того.

C>Этот блок кода может использоваться для разных целей:
C>1. Например, в ATL он используется для обхода ограничений WinAPI
C>(невозможность передачи контекста в оконную функцию).

Да, да. Видел я этот хак. Лет 8 назад я даже восхищался крутостью написашего это. Потом понял, что это некрутость, это выпендреж и мальчишество. Данное решение ровным счетом ничго не дает, за то завязывается на тонкие аспекты внутренней раализации работы Виндовс. Что по является грубейшей ошибкой.

C>2. В Win9x thunk'и использовались для прозрачных вызовов 32-битных
C>библиотек из 16-битного кода.

Ненадо песен. Там просто переходники. Динамически там ничего не делается. Да и проблемы перехода с одного устарелого С-АПИ на другой меня не трогают.

C>3. В ленивых языках thunk'и могут использоваться для оптимизации ленивых
C>вызовов и интероперирования.

Это все мертвому припарка. Реальное решение проблемы производительности ленивых языков — это переписывание кода компилятором. Ну, а вызов можно и через указатель сделать. "call регистр" еще никто не отменял.

>> C>Разница в скорости в разы.
>> Тесты в студию, плиз, с выкладками и доказательствами корректности.
C>Лень

Тогда выбросим аргументы за несостоятельсностью.

C>Вот тут рассказано о thunk'ах в Haskell'е для интероперирования с
C>нативным кодом:
C>http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/the-beast/fexport.html

А зачем мне это? В дотнете и так есть полноценный механизм интеропа.

VladD2 wrote:
> C>вместо указателя на целевую функцию используется указатель на
> C>динамически сгенерированный блок кода.
> Ну, и не надо тогда говорить про недостатки виртуальных машин. Твои
> thunk-и на фиг не упали для реализации нужной функциональности. То же
> самое можно реализовать на базе функциональных объетктов, генерации кода
> и кучи других вещей.
Нет, нельзя. Фактически нужна подмена кода в runtime — в .NET это
невозможно (без использования отладочных средств).

Собственно это и является фундаментальным недостатком управляемых сред —
если в VM нет нужного примитива, то его можно только эмулировать,
зачастую с гигантским оверхедом. На что апологеты VM отвечают обычно "а
нам это не нужно, все что может быть нам нужно в будущем уже сделали в VM".

> Хаскель медленен алгоритмически. И с этим ничего не поделаешь.
Ты согласишься работать на .NET VM, работающей в 5 раз медленнее текущей?

VladD2 wrote:
>> > Ага. Эрланг называется. Причем пашет даже под Виндовс.
> C>Эрланг — это скорее просто интерпретируемый язык.
> И среда выполнения реализующие вместе то о чем ты так мечтаешь.
Ага, для меня это идеал надежности.

> C>приложение ничего не сможет разрушить в своем окружении.
> По сути в Виндовс НТ приожение так же не может ничего разрушить вне
> своего процесса.
Ну да. Осталось только сделать создание процессов и межроцессные
коммуникации на порядок быстрее.

> Что до дотнета, то он гарантирует целостность памяти, а стало быть есть
> возможность востановления после сбоя. Применяя некоторые методики и/или
> системы контроля можно добиться очень высокой степени надежности.
Только вот эти "методики" не включают в себя try-catch в очереди
событий. Они включают в себя создание контролируемого окружения и
возможность его отката в случае ошибки.

В классических ОС то же самое делается с помощью (сюрприз!) процессов.

> Понимаешь в чем дело. Одно дело когда речь идет о повреждении памяти и
> полном хаосе, а другое когда речь идет предотвращении/выявлении ошибок.
> Система допускающая неопределенные состаяния по определению не может
> быть надежной.
Нештатный exception — это уже неопределенное состояние. Единственная
верная реакция на него — выбросить все окружение, которое могло привести
к ошибке. В ОС в этих случаях просто прибивают процесс (и запускают
новый если надо).

VladD2 wrote:
> C>Интероп сожрет больше времени на переключении managed/unmanaged.
> А ты выноси в анменеджед весь критичный кусок.
Я это и делаю — то есть пишу на С++

Вот к примеру, в текущем интерпретаторе работа со списками и переменными
является критически важной частью, НО не локализована в одном месте.

> C> unsafe в понятии C# весьма ограничен.
> Это безответсвенные заявления.
Почему? Фактически все что я получаю — это адресная арифметика.
Генерировать код в рантайме, играть со стеком (alloca), и т.п. я не могу.

> C>(http://www.perforce.com/jam/jam.html) — так простая оптимизация с
> C>хранением головной ноды списка непосредственно в объекте списка дала мне
> C>30% прироста скорости. Алгоритмы (а они там очень простые) уже были
> C>вылизаны до предела.
> А, ну, ну...
Можешь взять исходники: http://elewise.com/pubrepos/BuildPort/trunk/ и
посмотреть.

Здравствуйте, Cyberax, Вы писали:

C>Нештатный exception — это уже неопределенное состояние.
Вот только как в тойже винде гарантированно засечь то что в процессе что-то пошло не так из-за вахода за приделы массива?
Короче в С++ у нас UB, а в управляемой среде вполне себе определенное поведение... вылет исключения.

C>Единственная верная реакция на него — выбросить все окружение, которое могло привести к ошибке.
В управляемом приложении в таких случаях при правильном проектировании достаточно снести небольшую часть окружения.

C>В ОС в этих случаях просто прибивают процесс (и запускают новый если надо).
Это если AV таки произошло. А если нет?

WolfHound wrote:
> C>А куда пихать код эксплоита? Ну динамическую память тоже ставится
> NX-bit, а статические буфферы — в сегменте стека (и тоже NX).
> Придумают.
Не придумают. Эксплоиты с переполнением буфферов на нормальных
архитектурах не работают.

> C>В принципе, изредка остается еще ниндзя-трюк jump-to-library, но и от
> него можно защититься.
> Ну вот ты уже и придумал.
Эта дырка тоже закрывается.

> C>Это как раз пример того, что хакерские техники иногда нужны и важны.
> Глубоко в ядре. В реальном коде ниразу нужно небыло.
> Кстати, а зачем это в CLR?
Чтобы написать что-то типа CLR.

Здравствуйте, Cyberax, Вы писали:

>> C> unsafe в понятии C# весьма ограничен.
>> Это безответсвенные заявления.
C>Почему? Фактически все что я получаю — это адресная арифметика.
C>Генерировать код в рантайме, играть со стеком (alloca), и т.п. я не могу.

Насчет генерации кода в рантайме я просто даже и не знаю что сказать. Про Reflection.Emit Вы ведь не можете не знать. Может Вам нужна какая-то экстратеррестриальная генерация о которой я ничего не знаю?
А что касается стека... Есть stackalloc

klapaucius wrote:
>> > C> unsafe в понятии C# весьма ограничен.
>> > Это безответсвенные заявления.
> C>Почему? Фактически все что я получаю — это адресная арифметика.
> C>Генерировать код в рантайме, играть со стеком (alloca), и т.п. я не могу.
> Насчет генерации кода в рантайме я просто даже и не знаю что сказать.
Не байт-код, а настоящий машинный код (см. мое сообщение про thunk'и).

Поверьте, про генерацию байт-кода я знаю уже оооочень давно

Здравствуйте, Cyberax, Вы писали:

C>Не байт-код, а настоящий машинный код (см. мое сообщение про thunk'и).

Все ясно. Тут уж действительно, чего нет — того нет.

C>Поверьте, про генерацию байт-кода я знаю уже оооочень давно

Верю. Я смотрю вот в эти честные и чистые глаза и понимаю: они не солгут.

А в чем фатальный недостаток stackalloc ? Мне действительно интересно.

klapaucius wrote:
> C>Поверьте, про генерацию байт-кода я знаю уже оооочень давно
> Верю. Я смотрю вот в эти честные и чистые глаза и понимаю: они не солгут.
> А в чем фатальный недостаток stackalloc ? Мне действительно интересно.
В самом по себе — ничем, но он фундаментально unsafe. А зачем
использовать управляемую среду с неуправляемыми фичами?

Да и работа с unsafe-кодом в C# находится на уровне С. Нет ни умных
указателей, ни копикторов, ни деструкторов.

Здравствуйте, Cyberax, Вы писали:

>> А в чем фатальный недостаток stackalloc ? Мне действительно интересно.
C>В самом по себе — ничем, но он фундаментально unsafe.
Ну разумеется unsafe. Просто Вы сетовали на невозможность поиграться стеком в C# unsafe, вот я и удивился.

C> А зачем использовать управляемую среду с неуправляемыми фичами?
Вопрос вопросов. Полагаю, что в C# unsafe существует в основном для интеропа. Средство оптимизации, как я понимаю это доволно сомнительное, ведь оно мешает, по всей видимости GC и оптимизатору JIT но в некоторых случаях выигрыш получить можно. Смысл в том, что используя unsafe в управляемой среде можно явно обозначить ту часть кода где он применяется.
Все-таки есть разница используется опасный код повсеместно или нет. Не так ли?

C>Да и работа с unsafe-кодом в C# находится на уровне С. Нет ни умных
C>указателей, ни копикторов, ни деструкторов.
Но ведь в C++/CLI это все есть? Так что если очень хочется, то, видимо, можно?
Тем более, что в этом случае никакого сравнения нет с накладными расходами связанными с использованием неуправляемого кода. Все достаточно неплохо интегрируется, насколько я знаю, хотя сам досканально такие вопросы не изучал.
Так что thunk'и да, использовать нельзя, но все остальное — можно. Или нет?

Здравствуйте, AlexLion, Вы писали:

AL>Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов:
AL>1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается
AL>2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается

AL>Вопрос в том — какой бы вы вариант выбрали ( используете )

Безопасные варианты ровно до тех пор пока это не станет проблемой.

AL> и почему.
Потому что premature optimization is the root of all evil
Потому что 80% времени занимает исполнение 20% кода. Если вдруг окажется, что эта функция вызывается тысячу раз в секунду и является узким местом в программе, тогда и перепишешь её, чтоб работала побыстрее. Забегая вперёд, скажу, что эта ситуация очень маловероятна. Судя по названию функций, InvokeQuery будет требовать в разы больше времени.

Если же оптимизировать сразу, получишь мизерный выигрыш в производительности ценой ухудшения надёжности. И речь даже не столько о надёжности кода для тебя, сколько для того, кто будет его можифицировать в будущем.

Здравствуйте, WolfHound, Вы писали:

WH>Ну черная коробка это вобще не ОС. Обероновци толкают голубую бутылку. Но она не выдерживает критики ни по безопасности(,) ни то масштибируемости.
WH>В тоже время анилиз сингулирити откровенно слабых мест в общей концепции не выявил.

Я вот всё сообразить пытаюсь: это так C# и .Net на орфографию влияют или что-то еще? Хотя, с другой стороны, AVK, вроде, вполне грамотно пишет... Я прошу понять меня правильно: я не столько к орфографии цепляюсь, сколько пытаюсь разобраться: откуда такая небрежность в выражении своих мыслей возникает?

Если по существу, то общая проблема безопасности так просто не решается: не переполнение буфера, так забытое декорирование строк при составлении SQL запросов, не это, так хранение открытых паролей или персональной информации пользователей и т.п.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Я вот всё сообразить пытаюсь: это так C# и .Net на орфографию влияют или что-то еще?

Пашь, осбуждение орфорграфии — это п. 5. Ну, а ты мог бы и в командом форуме поговорить об этом.

ПК>Если по существу, то общая проблема безопасности так просто не решается: не переполнение буфера, так забытое декорирование строк при составлении SQL запросов, не это, так хранение открытых паролей или персональной информации пользователей и т.п.

То есть ты обосновываешь ненужность устранения одного класса ошибок (причем чаще всего на сегодня приводящего к уязвимостям в софте) тем что мол есть и другие ошибки? Интересное мнение. Можно его развить на обычную жизнь. Ведь мы каждый день переходя дорогу рискуем попасть под колеса. Значит и провода изолировать не надо.

McSeem2,

> http://msdn2.microsoft.com/en-us/library/kk6xf663.aspx
>

Copy a string. These functions are deprecated because more secure versions are available

>
> Это очередная параноя на почве дырявой безопасности в виндах. Эти наивные люди думают, что если запретить стандартную(!) функцию strcpy, то безопасность сразу повысится. Душит смех.

It's OK. Это не изобретение Microsoft, а детище стандартизаторов C. Просто Microsoft впереди паровоза, что некоторым образом даже хорошо. См. http://www.open-std.org/jtc1/sc22/wg14/www/docs/post-redmond-2004.htm и в частности http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1088.pdf.

Здравствуйте, VladD2, Вы писали:

ПК>>Я вот всё сообразить пытаюсь: это так C# и .Net на орфографию влияют или что-то еще?

VD>Пашь, осбуждение орфорграфии — это п. 5.

Зависит от.

ПК>>Если по существу, то общая проблема безопасности так просто не решается: не переполнение буфера, так забытое декорирование строк при составлении SQL запросов, не это, так хранение открытых паролей или персональной информации пользователей и т.п.

VD>То есть ты обосновываешь ненужность устранения одного класса ошибок (причем чаще всего на сегодня приводящего к уязвимостям в софте) тем что мол есть и другие ошибки?

Нет.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>(Я не представляю себе требования к памяти Photoshop на .NET ).

http://www.eecs.wsu.edu/paint.net/

Здравствуйте, klapaucius, Вы писали:

C>>Не байт-код, а настоящий машинный код (см. мое сообщение про thunk'и).

K>Все ясно. Тут уж действительно, чего нет — того нет.

Да тоже есть при желании. К примеру, можно поглядеть на transparent proxy/real proxy. Обращать внирмание на stub. Только смысла в этом никакого. Генерация кода при помощи JIT на голову удобнее, надежнее и проще.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>(Я не представляю себе требования к памяти Photoshop на .NET ).

AVK>http://www.eecs.wsu.edu/paint.net/

сравнил ворд с блокнотом

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>(Я не представляю себе требования к памяти Photoshop на .NET ).

AVK>http://www.eecs.wsu.edu/paint.net/
Это заявленные. А какая реальная конфигурация нужна чтоб работать а не тормозить?

Windows XP (SP1 or later), Windows 2000 (SP3 or later), Windows Server 2003, or Windows Vista
.NET Framework 2.0
400 MHz processor (Recommended: 800 MHz or faster)
128 MB RAM (Recommended: 512 MB or more)
1024 x 768 screen resolution
50+ MB hard drive space
64-bit support requires a 64-bit CPU that is running an x64 or Itanium edition of Windows XP or Windows Server 2003, and 256 MB RAM

у того же Photoshop CS2
Рекомендуемые с сайта (http://www.adobe.com/products/photoshop/systemreqs.html):

Intel® Xeon™, Xeon Dual, Intel Centrino™, or Pentium® III or 4 processor
Microsoft® Windows® 2000 with Service Pack 4, or Windows XP with Service Pack 1 or 2
320MB of RAM (384MB recommended)
650MB of available hard-disk space
1,024x768 monitor resolution with 16-bit video card
CD-ROM drive
Internet or phone connection required for product activation

более менее реальные требования к железу (из опроса по аське знакомых дизайнеров):

от Pentium 4 3Гц+
от 1 Гиг RAM
много of available hard-disk space
от 1280х1024 monitor resolution with 32-bit video card