| 2019-07-22 23:35 | Super-M | сайт не указан |
|
Всем здрасьте! Сайт скорее жив или как?
Здравствуйте! Конечно, жив. Обновляется просто не часто. А что?
|
| 2016-03-29 23:02 | Мухожук | сайт не указан |
|
> очень много пакетов к которым люди привыкли
Да, именно это я и имел ввиду. Вот тот же 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) оно особо не спасает, т.к. нужно дополнительно выбирать из предложенных вариантов нужный.
Когда приходится писать много кода, особое внимание уделяется даже таким мелочам.
Наконец, есть такая штука как привычка и вкус. А о вкусах не спорят, так что и рассуждения на данную тему давайте на этом закроем.
Спасибо за дискуссию.
|
| 2016-03-28 22:38 | Мухожук | сайт не указан |
|
> Не суметь нагуглить репозиторий MinGW с отдельными заголовочными файлами - это надо было постараться.
Я всего лишь сделал поиск в репозитории, выдало два файла:
/usr/include/boost/predef/os/windows.h
/usr/include/wine/windows/windows.h
Первое явно не то. Ставить wine ради одной программы - как-то нелогично, но можно отдельно поставить заголовки. Кстати частично даже работает.
> любой компилятор для Windows должен иметь в своём составе заголовочный Windows.h и необходимые библиотеки.
В Clang нету см llvm.org/releases/download.html
> Опять таки, в силу возраста, увлечённость новыми стандартами
Да нет, я не настаиваю, если больше нравится, используйте ANSI C, пожалуйста. Только вот определений из windows.h в этом стандарте тем более нету.
> Если кто-то сумел под иксами поставить Windows игру
Не обязательно ставить игру, чтобы хотеть извлечь из неё файлы. Например, есть проект Dune Legacy, позволяющий запустить Dune2 не используя оригинальный движок Дюны, а только файлы данных из неё (как раз те самые *.PAK). Подобные движки есть и для многих других старых игр, например C&C, Morrowind.
То же касается и Windows Installer: как раз на Windows его можно просто запустить и он сам всё извлечет из себя, а вот на других ОС и архитектурах распаковщик может понадобиться, поэтому желательно программы для извлечения этого файла писать так, чтобы они не требовали всякой фигни вроде COM и OLE.
> что очень неслабо увеличит размер программы
Можно использовать лёгкий тулкит, например fltk или tk, вряд ли там что-то сложнее формы с парой кнопок.
> А те кто сидят под иксами сами без проблем смогут собрать программу из исходных кодов
В некоторой степени это правда, но не потому что пользователи такие уж умные, а просто компилятор и все заголовочники или уже идут вместе с системой или устанавливаются одним щелчком, а вот в Windows скомпилировать что-то более сложное, чем hello world - это тот ещё квест.
> (в том числе и виндовых)
А вот это уже вряд ли. Например FAR Manager под линукс собрать никто так и не смог. В том числе и опытные программисты.
Кстати, попробуйте вы. Если получится - вам спасибо скажут множество пользователей, давно уже мечтающих перейти на другую ОС, но привязанные к Windows из-за FAR.
> а если не могут - значит рано ещё на иксы залезли.
Почему рано? Я по своему опыту вижу, что никаких особых требований к пользователю линукс не предъявляет, а использовать в повседневной деятельности его даже проще чем Windows, если нет изначальной привычки к Windows или конкретным программам под неё.
Хороший ответ. Серьёзно. "На провокации не поддаётся. Характер стойкий, нордический". (c)
> В Clang нету
Ещё раз "компилятор для Windows", т.е. компилирующий для этой платформы. Если ставить под Windows компилятор для Windows, то там должны быть заголовочные файлы. А так-то под Windows (т.е. работающие и компилирующие в Windows) и компиляторы для всяких SoC / Embedded систем есть, где, вообще, программа даже и не в x86 код собирается.
> Да нет, я не настаиваю, если больше нравится, используйте ANSI C, пожалуйста. Только вот определений из windows.h в этом стандарте тем более нету.
ANSI C указывает какие конструкции языка можно использовать, а какие нет. В стандарте не сказано, что запрещено подключать сторонние заголовочные файлы. Нужно разделять компилятор + синтаксис языка (ограниченный тем или иным стандартом) и платформу, на которой этот компилятор используется. Грубо говоря, есть кухонный комбайн (язык + стандарт), загрузив в который мясо получим фарш (одна платформа), а загрузив апельсины - сок (другая платформа). Так что код наших программ вполне легален в этом плане и не противоречит стандарту. Плюс нужно учитывать, что в некоторых программах удобнее использовать функции системы, типа, File Mapping в Windows. Если в иксах такие вещи и есть, то они будут делаться другой командой, т.е. всё равно придётся подгонять код define'ами под конкретную платформу. Упираемся в то, с чего начали: заморочек много, выхлопа мало. Есть ещё такая вещь как свободное время. Здесь мы занимаемся нашим хобби так, как нам это нравится, удобно и быстро. Это не наша работа, нам никто за это не платит, поэтому и какие-то требования к нашим программам предъявлять было бы неправильно.
> Не обязательно ставить игру, чтобы хотеть извлечь из неё файлы. Например, есть проект Dune Legacy, позволяющий запустить Dune2 не используя оригинальный движок Дюны, а только файлы данных из неё (как раз те самые *.PAK).
Автор(ы) сего проекта должен(ны) был(и) позаботиться о создании установщика для него, если проект задумывался как порт на другие системы (не DOS/Windows). При чём тут распаковщики на каком-то третьем сайте? Почему человек решивший поиграть в игру через порт должен искать к ней где-то распаковщик-установщик, а не взять его сразу на сайте проекта? Так что пример неубедительный.
> То же касается и Windows Installer: как раз на Windows его можно просто запустить и он сам всё извлечет из себя, а вот на других ОС и архитектурах распаковщик может понадобиться...
Можно, пожалуйста, пример, когда он может понадобится (не единичный)? После распаковки .MSI обычно получается те же яйца (программы под Windows), только сбоку. В частности так этот распаковщик на сайте и появился - одна программа от Microsoft была заточена на Windows 2000 и отказывалась устанавливаться где-то ещё, хотя прекрасно работала на Windows XP будучи распакованной из недр этого установщика. Т.е., как ни крути, для того чтобы что-то сделать с результатом распаковки всё равно понадобится Wine или какая-то другая виртуальная машина. А использовать возможности самой системы по распаковке через COM/OLE куда проще, чем писать распаковщик с нуля (и не факт, что формат .MSI не является закрытым - тогда, вообще, непонятно сколько на всё это времени и сил уйдёт и получится ли хоть что-то в итоге).
> Можно использовать лёгкий тулкит, например fltk или tk, вряд ли там что-то сложнее формы с парой кнопок.
Посмотрим, спасибо. Если программа не заточена на Windows-only компоненты, то, наверное, с этим можно заморочиться. В принципе. Но быстрее и проще сделать так как уже привычно - через WinAPI.
> В некоторой степени это правда, но не потому что пользователи такие уж умные...
Установка иксов, как бы, подразумевает далеко не начальный уровень пользователя (хотя, конечно, с Ubuntu и прочими Windows-like системами, где пользователь ничем, кроме хождения по Интернету, просмотра фильмов, прослушивания музыки и набора кое-каких документов не занимается, ситуация сильно изменилась). И собрать что-то, даже под иксами, не всегда просто - приходится искать и ставить кучу сторонних пакетов. Т.е. программа реально из двух-трёх строк, но зависимостей при этом за собой тащит столько, что устаёшь искать и ставить пакеты. Особенно "веселит", когда один, только что скачанный и установленный пакет, не собирается без какого-то другого. Похоже что эта проблема наблюдается на любой платформе.
> Например FAR Manager под линукс собрать никто так и не смог.
Он слишком сильно заточен на Windows.
> Почему рано?
Действительно, если ничего сложного за компьютером не делать, то и иксы сойдут (см. выше про Ubuntu). Плюс под Windows (так исторически сложилось) очень много пакетов к которым люди привыкли, к тому же альтернатива под иксы не всегда настолько же функциональная - зачастую нехватает возможностей (или их нет вообще). Вообще же, иксы - это изначально серверные системы, несмотря на то, что их упорно пытаются натянуть на десктопы (настольные компьютеры).
|
| 2016-03-27 22:55 | Мухожук | сайт не указан |
|
А чем плоха замена на < > например (если опять съестся: < > )
А где [windows.h] предагаете брать?
Пробовал поискать, выдало ссылку на wine1.4-dev.deb, там 21 мегабайт файлов и одним windows.h не обойтись, так как он включает другие файлы.
Это нормально, что для сборки трёхкилобайтной программы требуется качать 21 мегабайт заголовков?
Если добавить его в путь поиска, то уже ругается на undefined reference to `_stricmp' или . Опять что-то нестандартное. Пришлось переименовывать в strcasecmp с помощью #define. Что мешает так писать программу, чтобы собиралось сразу, а не приходилось выискивать заголовочники непонятно где, например все нестандартные определения в свой файл класть и прикладывать его?
Я думаю, если писать на C, то нужно соответствовать стандартам языка (C11 или хотя бы C99), а если включается что-то, что не описано в стандарте, то надо сразу писать, в какой библиотеке это берётся.
1) Ещё раз: движок сайта старый. Там очень много функций завязанных одна на другой.
2) Не суметь нагуглить репозиторий MinGW с отдельными заголовочными файлами - это надо было постараться.
Вообще, у вас несколько проблем из-за которых мы сейчас бессмысленно и бесполезно дискутируем тратя время зря:
1) Ваш юный возраст (на что указывает попытка найти ошибку с типами данных там, где её нет).
2) Приверженность, в силу возрастного максимализма и перфекционизма, иксам, ибо любой компилятор для Windows должен иметь в своём составе заголовочный Windows.h и необходимые библиотеки.
3) Опять таки, в силу возраста, увлечённость новыми стандартами ("ново", "модно", "C11" и прочее такое не есть синоним "толково и хорошо").
Намёк на возраст ни разу не уничижительный, если что, но некоторые вещи, действительно, приходят к человеку с годами - в этом нет ничего зазорного. Например, если что-то МОЖНО сделать, это совсем НЕ значит, что это НУЖНО делать. Можно заморачиваться с типами данных, но это не значит, что это нужно делать. Игры, распаковщики к которым мы пишем, сделаны под Windows (изредка под DOS). Если кто-то сумел под иксами поставить Windows игру (под Wine), то найдёт способ и запустить распаковщик. Исходные коды лежат для тех, кто хочет сделать какую-то модификацию распаковщика или игры (подсмотреть алгоритм, чтобы запаковать обратно). Заголовочные файлы (см. ссылку выше) найти не проблема. К тому же у нас на сайте есть некоторые программы, типа распаковщика Windows Installer, которые, во-первых, сделаны с Windows GUI (чтобы была переносимость придётся использовать GTK, QT или как там оно, что очень неслабо увеличит размер программы - соотношение полезного кода к толстенным многомегабайтным библиотекам, которые конечному пользователю придётся выкачать), плюс COM и прочие OLE, которых нигде, кроме Windows, нет, а поэтому и делать кроссплатформенную программу просто бессмысленно (можно, но не нужно). Наконец, наши работы используются в других программах и даже языках программирования (переписаны на Python, например) - пока что никто не жаловался на "нестандартные" типы данных. Что говорит о том, что те кто хотел скомпилировать - молча скомпилировали. А если нет - значит оно им не особо и нужно было. Это тоже один из признаков зрелости - не придираться по пустякам, а молча делать, если нужно. "Кто хочет - ищет способ, кто не хочет - причину". (c) Мы намеренно не используем в наших программах какие-то сверхредкие библиотеки, которые сложно или невозможно достать. Наши программы (.EXE файлы) работают с Windows 98 до Windows 10 включительно. Плюс программы компилируются под Windows без единой ошибки и предупреждений (/mingw/gcc -Wall -ansi -pedantic filename.c), потому что мы компилируем, где это возможно, в стандарте C'89 (1989 года), что гарантирует сборку программы на более новых компиляторах и не заставит людей обновляться до непойми чего. Считаем, что этого всего более чем достаточно. У Windows гораздо больше аудитория, чем в иксах. А те кто сидят под иксами сами без проблем смогут собрать программу из исходных кодов (в том числе и виндовых), а если не могут - значит рано ещё на иксы залезли.
Всё изложенное выше написано без обид, желания оскорбить и других намёков.
|
| 2016-03-27 17:01 | Мухожук | сайт не указан |
|
Скачал одну программу наугад, уже в пятой строче ошибка:
untrmpak.c:5:21: fatal error: windows.h: No such file or directory
Чтобы программа скомпилировалась, пришлось её удалить и написать вот это:
#include (stdint.h)
#define BYTE uint8_t
#define DWORD uint32_t
#define LOWORD(x) (x&0xFFFF)
#define HIWORD(y) ((y((16)&0xFFFF)
Почему вы не используете стандартные uint8_t и uint32_t а берёте какие-то ассемблерные BYTE и DWORD, которых нету в стандарте?
Да у вас ещё и гостевая кривая — заменила ( ) на круглые скобки. Ну, надеюсь, сами разберётесь, как должно быть.
Спасибо за сообщение. По порядку:
1) С типами не всё так просто. Во-первых, писать буквенно-цифровые имена типов неудобно, к тому же оно смотрится громоздко и некрасиво. Во-вторых, если делать всё строго, то, помимо разрядности, нужно ещё и тип переменных указывать - big endian или little endian. Т.е. получается что-то ужасно чудовищное типа "uint32le_t". А BYTE, WORD и DWORD - это всё из Asm x86, к тому же у нас есть несколько программ со вставками на нём. Тут и разрядность понятна и тип. А кому надо поиском с заменой переделают. К тому же можно просто подключить Windows.h - заголовочный файл не требует дополнительных библиотек для линковки, зато указанные выше типы и макросы сразу станут доступны. Наконец, главное в программе это не то как обозвали типы, а алгоритм.
2) Насчёт замены скобок - да, мы в курсе. Движок сайта старый, так что, дабы избежать JavaScript/HTML-инъекций все угловые скобки заменяются на круглые.
|
| 2016-02-01 22:48 | RAYN3 | сайт не указан |
|
Давно здесь не был! Чертовски рад что дело живет и процветает! 
А ведь в этом году у сайта юбилей.. Помнится и про экстрактор к bloodrayne 2 в
локализации буки. Готов оказать некоторую фин поддержку
 проекту, но не найду реквизитов
О! Какие люди! Здорово, что ты зашёл! См. почту - все подробности там. Насчёт копилки - см. последние новости (третья новость сверху). Один хороший товарищ обещал помочь, так что, думаю, в ближайшее время восстановим копилку.
|
| 2014-08-20 15:40 | Guest21 | сайт не указан |
|
Здравствуйте! Где можно скачать bnkextr.zip? По ссылке
http://ctpax-cheater.losthost.org/personal/bnkextr.zip не качается :(
Здравствуйте! Спасибо, поправили. На данный момент сайт снова доступен.
|
| 2014-07-31 16:46 | Phoenix | сайт не указан |
|
У вас очень полезные утилиты выложены, да ещё и с исходными кодами, что позволяет их развивать. Спасибо!
Не за что, обращайтесь. Реквизиты нашей копилки слева, под меню.
|
|
Hey. You seem to have a bug on the site. Trying to add comments is met with error.
Hello. It's probably a spam filter - sorry and please use email at the about page - just in case we sent you one.
|
| 2013-12-30 21:07 | Андрей | сайт не указан |
|
Надо ли для улучшения качества mp3 выставлять в NFS Multimedia
converter качество кодирования на 9?
Нет. Наоборот - нужно ставить 0 (ноль). Если навести на этот пункт мышкой, то появится всплывающая подсказка, где это всё объяснено. Помимо этого для достижения лучшего качества следует выбрать "MPEG 1 Layer III 320kbps".
|
| 2013-02-26 21:08 | Guest | сайт не указан |
|
Хотелось бы присоединиться к Peter с пожеланиями развития ToWav Music Converter, в том плане, чтобы можно было использовать для конвертации *.fsb файлов с таких игр, как DoW 2 + addons.
С надеждой!
У нас нет исходных кодов этой программы.
|
| 2013-02-14 00:27 | Peter | сайт не указан |
|
Здравствуйте. Хотелось бы попросить товарища Xplorer создать
новую версию ToWav Music Converter, чтобы он мог конвертировать
snu в wav из игры Dead Space 2, так как старая версия их не
конвертирует, разве только некоторые. И чтобы перегоняла wav
обратно в snu. Пожалуйста, сделайте доброе дело, хотя бы ради
фанатов Dead Space, которые уже два года ждут русскую озвучку.
Озвучивать проект будет студия GamesVoice.
Xplorer неактивен с ноября 2010 года. Если он появится, то мы ему передадим.
|
|
pPlease make Nfsconverter for Mostwanted 2012
Use ealayer3 (see docs for NFS Multimedia Converter) with this game.
|
| 2012-09-16 21:26 | Guest | сайт не указан |
|
Оказывается ехе-шник от акеллы подходит для snowball, вопрос
снят. Спасибо за то, что пошли навстречу. :)
Да, в общем-то, не за что. Raf-9600, кстати, ещё тогда писал в личке: "Просто случайно удалил файл английских шрифтов (русские в другом файле хранились), потому и были кряобрязины. На самом деле даже даже Акелловский exe'шник нормально работает на английской версии...". Так что если будут какие-то проблемы - не стоит трогать файлы шрифтов (или наоборот - скопировать, если их нет). Кстати, в теме добавлен универсальный nocd-патч, который должен ставиться на любую из тех трёх версий.
|
| 2012-09-16 20:23 | Guest | сайт не указан |
|
Спасибо, у меня есть два ехе-шника от русских локализаций:
http://www.sendspace.com/file/ur13m1 Собственно мне отучалка для
версии snowball нужна, от английской версии не надо.
|
|
|
