> очень много пакетов к которым люди привыкли
Да, именно это я и имел ввиду. Вот тот же FAR, например. Вот я честно не понимаю, что в нём такого: ну подумаешь ещё один клон Norton Commander, который мне надоесть успел ещё когда я пользовался DOS. А им почему-то неприменно надо именно FAR.
> Установка иксов, как бы, подразумевает далеко не начальный уровень пользователя
Кстати, почему "иксов"? "Иксы" - это X Window System, только один из компонентов системы GNU/Linux или BSD, не обязательный для работы. Даже в принципе графический интерфейс уже можно гонять через Wayland.
> Т.е. программа реально из двух-трёх строк, но зависимостей при этом за собой тащит столько, что устаёшь искать и ставить пакеты.
Это зависит от дистрибутива и программы. Если какая-то не слишком редкая, то есть как правило способ поставить все зависимости сразу одной командой. Например в Gentoo ebuild/emerge, в *BSD ports, в Source Mage GNU/Linux Sorcery и так далее. Ну и даже в убунте есть волшебная команда apt-get built-dep (пакет), которая автоматически установит всё что нужно для сборки пакета. Кстати по идее в msys и cygwin тоже должен быть менеджер зависимостей.
> Можно, пожалуйста, пример, когда он может понадобится
Да множество примеров, когда интересна не сама программа, а ресурсы из неё - картинки, музыка, карты и тд. Впрочем, тот же 7zip умеет распаковывть MSI по идее. И ещё одна реализация распаковщика есть в комплекте wine.
Кстати, wine - не виртуальная машина, а просто другая реализация windows api + стандартных утилит и загрузчика PE.
> Почему человек решивший поиграть в игру через порт должен искать к ней где-то распаковщик-установщик
Да нет, чтобы просто поиграть в Dune Legacy, достаточно только самих PAK файлов, игра их распаковывает сама. Вот их они не распространяют из-за копирайта и нужно где-то отдельно искать досовскую версию игры. Но что, если захочется поковыряться в самом файле и сделать мод? Это просто был пример, что желание распаковывать специфические форматы не означает наличия установленной wine/windows.
> В стандарте не сказано, что запрещено подключать сторонние заголовочные файлы.
Но ведь всё-таки есть принципиальная разница между каким-нибудь stdint.h и windows.h, разве нет? Есть заголовочные файлы, типы и фукции, гарантированные стандартом, например stdio.h, int, strcmp, а есть те, которые в стандарте не упомянуты: windows.h, DWORD, stricmp или какие-нибудь.
> функции системы, типа, File Mapping в Windows
А разве нельзя воспользоваться функцией mmap (sys/mman.h)?
> Ещё раз "компилятор для Windows", т.е. компилирующий для этой платформы. Если ставить под Windows компилятор для Windows, то там должны быть заголовочные файлы.
А разве clang для windows не такой? По идее он как раз и предназначен, чтобы комплировать программы для Windows, запущенный при этом под ней же (если говорить именно о windows-версии).
Стандартные заголовочные файлы там все есть - stdio.h, ctype.h, math.h и так далее, а windows.h в стандарте нет, значит и предоставлять его компилятор, в том числе и виндовый, генерирующий виндовые бинарники, не обязан. Или я что-то не так понял и какой-то стандарт, требующий поставлять windows.h есть?
> Это не наша работа, нам никто за это не платит, поэтому и какие-то требования к нашим программам предъявлять было бы неправильно.
Да, согласен, но если допускать использование дополнительных фишек, которых в ANSI C не описаны, то почему бы и не проапрейдиться до C99 или даже C11, и не использовать те же строчные комментарии, например? Всё-таки с момента принятия C99 уже лет 17 прошло, за это время все актуальные компиляторы должны бы уже подтянуться.
А если стремиться соответствовать стандарту — то почему бы не обойтись без windows.h, хотя бы в случае можно без проблем взять что-то другое, например unsigned char или даже int (современные процессоры с ними работают быстрее) вместо BYTE?
> Кстати, почему "иксов"?
Это пошло с того времени, когда Unix, Linux и т.д. Они все на икс заканчивались.
> Да множество примеров, когда интересна не сама программа, а ресурсы из неё - картинки, музыка, карты и тд.
Это уже, скорее, игра какая-нибудь, а не софт. К тому же зачастую во многих играх файлы упакованы каким-нибудь Windows-установщиком (обычно Install Wizard Shield).
> Кстати, wine - не виртуальная машина, а просто другая реализация windows api + стандартных утилит и загрузчика PE.
Ну и как это всё, в сумме, называется? Пусть будет эмулятор. Не суть.
> Но что, если захочется поковыряться в самом файле и сделать мод?
"Без пруда не вытащишь рыбку из него." (c) А кому сейчас легко?
> Но ведь всё-таки есть принципиальная разница между каким-нибудь stdint.h и windows.h, разве нет?
...
> А разве нельзя воспользоваться функцией mmap (sys/mman.h)?
Вот это было реально смешно. "sys/mman.h" примерно из той же оперы, что и "windows.h", причём последний в MinGW даже более нового стандарта C'99 есть, а "sys/mman.h" - нет.
> Или я что-то не так понял и какой-то стандарт, требующий поставлять windows.h есть?
Скажем так: какой большой смысл в компиляторе под Windows, если заголовочных файлов под эту систему нет? Не говоря уже о всяких более специфичных вещах, типа DDK.
> ...за это время все актуальные компиляторы должны бы уже подтянуться.
К сожалению, нормальных компиляторов для Си под Windows тупо нет. Они либо генерируют кривой и/или толстый код, либо с кучей зависимостей от библиотек, которых нет в ядре системы и нужно ставить отдельно, либо ещё что-нибудь. Поэтому используем GCC 3.2 (2002) с некоторыми хаками, чтобы оно было совместимо с системами начиная от Windows 98 по Windows 10 включительно.
> А если стремиться соответствовать стандарту — то почему бы не обойтись без windows.h, хотя бы в случае можно без проблем взять что-то другое, например unsigned char или даже int (современные процессоры с ними работают быстрее) вместо BYTE?
Стремиться соответствовать чему-то только ради самого соответствия бессмысленно. Должна быть какая-то утилитарная цель, иначе это напрасная трата времени.
Чтобы не продолжать дальше этот диалог (уж очень он много времени отнимает), объясним на примере:
1) Пример первый:
unsigned int size;
unsigned char flags;
2) Пример второй:
uint32le_t size;
uint8le_t flags;
3) Пример третий:
DWORD size;
BYTE flags;
Третий пример быстрее всех набирается - достаточно придавить мизинцем Shift.
Для первого нужно писать километровые unsigned, к тому же если один из типов со знаком, то код ещё и зрительно будет вырвиглазно смотреться и читаться:
int size;
unsigned char flags;
Типы в Windows.h (BYTE, WORD, DWORD) короткие и глаз сразу схватывает размер структур и их расположение.
Для использования второго примера нужно ещё и тащить руки либо в правую часть клавиатуры, либо вверх к цифрам, плюс ещё Shift и минус, чтобы написать подчерк.
Конечно, есть автозавершение, но в ситуации, когда три типа, и все начинаются на "uint" (uint8le_t, uint16le_t, uint32le_t) оно особо не спасает, т.к. нужно дополнительно выбирать из предложенных вариантов нужный.
Когда приходится писать много кода, особое внимание уделяется даже таким мелочам.
Наконец, есть такая штука как привычка и вкус. А о вкусах не спорят, так что и рассуждения на данную тему давайте на этом закроем.
Спасибо за дискуссию.
А тут практикуют распаковщики на шарпе?