Pull to refresh

Comments 34

// Это может быть и "edit"u8, но вывод в виде числовой константы little-endian занимает меньше места
long className = 'e' | 'd' << 8 | 'i' << 16 | 't' << 24;

IntPtr hwnd = CreateWindowExA(WS_EX_APPWINDOW | WS_EX_WINDOWEDGE, (byte*)&className, null,
WS_VISIBLE | WS_CAPTION | WS_CLIPSIBLINGS | WS_CLIPCHILDREN,
0, 0, Width, Height, 0, 0, 0, 0);

Возможно я не знаю каких-то подводных камней на C#, но кажется тут не хватает нулевого байта для завершения строки. Может стоит дополнить статью комментарием, почему это работает?

long - 8 байт, так что там аж 4 нулевых байта после edit.

После того, как хватанул веселостей из-за разных трактований sizeof(long) на Windows-Linux-32-64, просто принял для себя всегда писать типы из stdint - uint64_t, int8_t. В шарпах поступаю так же - не пытаюсь запоминать, а беру UInt64.

Стоит иметь ввиду, что обычно стандарт кодирования C# это использование ключевых слов вместо полных имён System.Int64.

ну эти предупреждения и отключить можно

С другой стороны, строка в 5 байт меньше, чем long в 8. Опять же непонятно, в чём тут экономия.

Шарповые строки внутри UTF16, так что string будет больше. Честный массив байт будет больше наверняка из-за выравнивания и оверхеда. Но все это предположения.

Тут вообще шарповые строки никак не участвуют. Вызывается чистый WinAPI (CreateWindowExA), куда в параметр "имя класса" вместо ожидаемого PCHAR передаётся вообще &UINT64.
Для CreateWindowExW будет нужен буфер 10 байт, с учётом nul-терминатора, что в UINT64 не помещается.

Вместо того, чтобы добавлять то, что нужно, приходится убирать то, что не нужно, которого еще и на 4 десятичных порядка больше.

Тьфу. Отвратительно. И этот язык признан языком года?

Вы видимо на языках ассемблера пишете

Параметры по умолчанию ориентированы на максимальную универсальность, отсюда и размер. Многие приложения использую ту же рефлексию, которая не будет работать после манипулиций из статьи.

kkrieger вспомнился)

Это который при размере ~100КБ занимал 250-300МБ оперативки?

Автор еще так скромно умолчал, что bflat он и сделал :)

Перевод местами корявый, например "глобализация инвариантов" должна быть "инвариантной глобализацией, но это не важно, так как статья интересная и заслуживает внимания.

Продолжайте в том же духе и выискивайте интересные статьи!

Так же радует развитие .NET. Во времена .NET Core 2 альфа-версии AOT ужимали hello world до 4.5 МБ. Теперь это меньше мегабайта. Возможно MS используют наработки автора для ещё большей степени сжатия.

А экстремальный вариант от автора, который по сути состит из вызова консольных команд (что можно автоматизировать до клика одной кнопки) может дать новые ниши .NET, тот же Ардуино. Высокоуровневые языки тоже могут в маленький бинарнин, люди пусть пишут понятный код на языке высокого уровня, а ужимать до маленьких размеров должны алгоритмы (придуманные человеком ну или ИИ).

За упоминание ардуины отдельное спасибо, душа болит что на шарпе нет возможности, на луа есть, на питон есть, а шарпа нет(

Было, но давно умерло, толком не родившись.

То что там было зачем-то пыталось именно IL код исполнять. а вот через NativeAoT было бы интересно.

Вот их пропустил, спасибо. Вроде нативный код как раз, можно глянуть.

а разве те AVR-ки, что в Ардуино стоят, не слишком слабенькие для nano?

в итоге потыкав, не нашел нативный код, но нашел про интерпретацию. грустно.

спасибо за статью! очень познавательно!
под интроспекцией имеется в виду reflection?

Утверждают, что один настоящий программист умудрился засунуть прграмму распознавания образов в несколько сот байт неиспользованной памяти корабля "Вояджер", которая осуществляла поиск, обнаружила и сфотографировала новую луну Юпитера.

"Настоящие прграммисты не используют Паскаль"

А самого кода лабиринта нет, очень жаль. Интересно же, какие там оптимизации

Я все понимаю, но почему CreateWindowExA, а не CreateWindowExW? Мы вернулись в светлый 98 год?

Тут же ненормальная оптимизация.
Юникод-строка "Edit" не поместилась бы в 8 байт, т.е. в long.

Полагаю, это сделано для ещё меньшего размера, ведь A вариант принимает кодировку Ansi, которая позволяет уместить строку "edit" в тот самый один long, а вот utf-16, принимаемая W вариантом, с учётом завершающего нуля потребует уже больше места, что выльется в лишние инструкции и константы, увеличив размер программы.

ну так и что получается: заголовок громкий, а по факту использование давно депрекейтнутых api, поддержка которых не выпилена по недоразумению

Sign up to leave a comment.