Если нравится наш проект, пожалуйста, поддержите любой приемлимой суммой чтобы помочь оплачивать хостинг. Спасибо!
Навигация  🇷🇺RU | 🇬🇧EN

Новые комментарии

Последние файлы

Пожертвования
[ Через Yoo.Money ]
(бывшие Яндекс.Деньги) 410011494554572

Contact us if you wish
PayPal or BitCoin donation

Наши друзья

Гостевая книга
Ваше имя
e-mail адрес
WEB-страница
C0DE IM@GE
Текст сообщения
biggrinconfusedcoolcry
evileeklolfrown
mrgreenredfacemadneutral
razzrolleyessadsmile
surprisedtwistedwinkarrow
exclaimideaquestionthumbsup

 2019-08-05 18:23 Rash_forever сайт не указан 

Ребят отправил проекту небольшую денежку мож мало чем поможет но всеже

удачи вам в вашем деле спасибо за отзывчивость, за идею главное не покидайте

проект! Еще раз спасибо))))


Знаю задолбал((( А почему рега на форум не работает((


Большое спасибо за поддержку нашего проекта! Что касается регистрации, то указанный e-mail адрес рабочий? Если да, то можем на него зарегистрировать нового пользователя (к сожалению, регистрация в ручном режиме из-за спамеров и неадекватов). Просим отнестись с пониманием. Проверьте почту, там должна быть ссылка для входа на форум. У нас на форуме есть правила, пожалуйста, прочтите их перед тем как что-то писать. Спасибо!



 2019-08-04 14:14 Rash_forever сайт не указан 

Еще раз привет! Ребят а че статьи никакие не выкладываются типа распакуй

файло на Си и т.д. интересно почитать, пробовал аналог на шарпе(Delphi

Generals) чет дилетант пока еще, основы знаю а вглубь не получается но

всеравно статьи такие толкают на пробы)))


И ещё раз здравствуйте! К сожалению, сейчас нет времени статьи писать, в основном отдельные какие-то моменты разобраны в темах на нашем форуме. Хотя, безусловно, новые статьи необходимы. Самое близкое, что когда-то было сделано, по написанию программ на ANSI C можно прочитать здесь. В остальном - скачивайте программы с нашего сайта (желательно из последних обновлений - они переписаны и теперь аккуратнее, чем старые) и смотрите как и что там устроено. Если есть вопросы по программированию, то с удовольствием ответим, можем даже на форуме зарегистрировать (пишите на почту или в обратную связь: нужен будет e-mail и логин для регистрации на форуме). Для "пробы пера" попробуйте пределать распаковщик EA Unpacker у нас на сайте с Delphi на ANSI C. Это не должно быть особенно сложным и, как уже говорилось, можем помочь советами - всегда рады новым людям, которые интересуются распаковкой игровых ресурсов.



 2019-07-30 19:37 Rash_forever сайт не указан 

Всем привет! Сайт жиииив А тут практикуют распаковщики на шарпе?


Здравствуйте. Интересно, что о живости сайта судят по гостевой книге, а не постоянно обновляющихся новостях, добавленных на сайт новых программах или ответах в комментариях... Ну да ладно. Так сложилось, что на шарпе никто не пишет, но это почти что язык программирования, так что, если есть желание, можем помочь освоить ANSI C в необходимых для написания распаковщика или конвертера объёмах. Кстати, см. новость от 2019-03-03 на главной.



 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 Мухожук сайт не указан 

А чем плоха замена на < > например (если опять съестся: &lt; &gt; )


А где [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 сайт не указан 

У вас очень полезные утилиты выложены, да ещё и с исходными кодами, что позволяет их развивать. Спасибо!


Не за что, обращайтесь. Реквизиты нашей копилки слева, под меню.



 2014-01-29 22:14 AliceShade сайт не указан 

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 года. Если он появится, то мы ему передадим.



[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] 
    © CTPAX-X 2006-2024 | engine version 2.5
Based on original site design by Blade

 

 

 
При копировании материалов ссылка на сайт WWW.CTPAX-X.ORG обязательна!
Использование материалов влечёт безоговорочное принятие правил сайта.
Количество запросов к БД: 7 | Страница сгенерирована за 0.007576 сек.