Только 2 кнопки / сек с добавлением importprivkey?

Как идет его так медленно, чтобы добавить частные ключи с помощью importprivkey?

На 1.8GHz машине Intel Dual Core, где bitcoind хранится на большом псевдодиска суммарная скорость составляет около 2 ключа / второй.
CPU находится в режиме ожидания на 0-1%, означает, что массивное время впустую впустую.

Является ли это интерфейс RPC, что так медленно? Если база данных будет работать трудно было бы показать в использовании процессора. Но нет ни одного. Для известково публичных хэши / адресов и т.д., также не является ограничивающим фактором, так как он будет отображаться в диспетчере задач. И да, я поставил Пересканировать ложь ..

Я использую C # код, базовый пример здесь:

Однако его с той же скоростью, чтобы просто позвонить bitcoind через cmd.exe и добавить необходимый Params для importprivkey. Поэтому его не в C # проблемы.

Что-то здесь не так ..

Кажется, в настоящее время единственный быстрый способ добавить ключи непосредственно wallet.dat, которая является довольно болезненной задачей закодировать под виндой ..

Установите третий параметр importprivkey ложь, чтобы избежать blockchain пересканирования, то операция очень быстро. Выполните повторное сканирование только на последнем privkey вы хотите импортировать.

Здравствуй,

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

Вместо бага поохотиться мою машину, позволяет собирать статистику.

Как быстро вы можете импортировать ключи с importprevkey через JSON-RPC и имеющий полный клиент Bitcoin на Ramdisk с любыми 3 Гб / с или около скорости ввода / вывода? Позволяет составить конкуренцию импортировать 10.000 частных ключей .. Доказательство того, что я не прав, чтобы сказать, что нынешний путь клиент имеет дело с Bitcoin importprevkey так же глупо, как я думал, что BASIC изменит мир в школе, когда я был моложе клещ.

Я начал:

2 ключа / сек .. Intel Dual Core 1,8 ГГц, C # код - бить это!

Является ли это действительно проблема, что вам потребуется более 2-х ключей в секунду.

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

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

Есть ли разница в скорости между Пересканировать и выключается?

Если трудно база данных работает это не обязательно проявляется в использовании процессора. Многие операции с базой данных O оценка I /, так что, возможно, проводит большую часть времени в ожидании диска.

Когда я использую pywallet сливаться бумажники, она занимает около 2мин 200 адресов, так что меня не шокирует
Это обработка ключа, который занимает некоторое время

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

Кто-то может настроить pywallet в функции слияния бумажник и положил таймеры, чтобы найти медленную линию (s)

Я просто проверял и импортировала 20 ключей в соответствии с 100мс из командной строки (в том числе время, чтобы вилка) с bitcoind мерзавца примерно неделю назад.

Я подозреваю, что вы предоставляете повторное сканирование флага в качестве метки.

Из командной строки правильный вызов является:

Код:

bitcoind importprivkey 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx "" ложный

С "" будучи на этикетке.

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

Цитата: gmaxwell от 05 апреля 2013 года, 7:13:01 PM

Я подозреваю, что вы предоставляете повторное сканирование флага в качестве метки.

Это было мое подозрение, как хорошо, но из связанного кода: это выглядит как ярлык "NewKeyName" передается. Поэтому мой вопрос / ложь делает ли Пересканировать истинное значение. Я бы ожидать, что это будет гораздо медленнее, чем две клавиши в секунду с пересканирует.

Цитата: gmaxwell от 05 апреля 2013 года, 7:13:01 PM

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

котировка

Я бы ожидать, что это будет гораздо медленнее, чем две клавиши в секунду с пересканирует.

И то, и также, если это правда, то процессор должен был на 100%? Если вы используете псевдодиск, есть не намного больше, чтобы замедлить его ...

Использование мода версии C # Casascius Bitcoin-адрес-Utility (https://github.com/casascius/Bitcoin-Address-Utility) Я мог бы генерировать личные ключи от случайных фразах, плюс их BTC адресов со скоростью 11 клавиш / с и 50% загрузки процессора (Intel Dual Core 1,86 ГГц, нет HT).

Таким образом, должна быть около 20 клавиш / с с многопоточным кодом по сравнению с 2,8 ключей / с bitcoind с его странной 0-1% загрузкой процессора.

Я подозреваю:

1. Сканирование бумажник, чтобы увидеть, если он уже в бумажнике, и / или
2. Выполнение валидности проверки, чтобы убедиться, что ключ подходит.

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

Окна около 5x медленнее при выполнении команды RPC, чем Linux.

Цитата: PoorGirl 10 апреля 2013, 10:25:40 PM

Ммм. Генерирование вовсе не то же самое, как импортировать. Импорт представляет собой запись процесса учета / верификацию, где в качестве генерации является процессом математики. Генерация ключа из ключевой фразы является довольно быстрый хэш только процесс. Я ожидаю, генерируя использовать процессор гораздо больше, чем импортировать.

Ключевой процесс проверки должен быть факультативным в свое время дорого. Я уверен, что мои сгенерированные ключи действительны, так что я просто хочу, чтобы импортировать их без проверки. Для того, чтобы создать ключ DEP и записать его wallet.dat не дорого.

Для того, чтобы увеличить скорость импорта я побежал несколько приложений importprivkey Rpc параллельно:

10 параллельных приложений = аварии через 5 мин
5 parallell приложения = авария после 12 часов, но, наконец, использование ЦП bitcoind поднялось до 50%, а скорость импорта также значительно быстрее. Подобно мое моделирование.

Таким образом, кажется, что bitcoind не любит параллельную Rpc команды и получает hickup где-то.

Таким образом, идеальным решением было бы:

- сделать путь кода для importprivkey многопоточного везде, где это возможно (OpenMP или автоматическая с компиляторов Intel C ++)
- позволяют параллельные команды входящие RPC. Если больше команд RPC приходят могут быть обработаны сохранять их в буфере и работать их позже или ответить с кодом ошибки 0 для "занятый",

Я не могу скомпилировать bitcoind на Windows. Если однодневные есть рабочий проект VS2012 Я рад помочь.

Параллельный импорт означает параллельное wallet.dat модифицирование
Я думаю, что это проблема

Цитата: PoorGirl 13 апреля 2013, 12:36:57 PM

Я не могу скомпилировать bitcoind на Windows. Если однодневные есть рабочий проект VS2012 Я рад помочь.

Создание VS2012 проекта Bitcoind должно быть довольно выполнимо (если вам не нужен графический интерфейс, Qt + MSVC несколько сложнее). Я сделал это один раз, но крайне устарели, так, вероятно, бесполезно. Тем не менее, у меня нет бегущего окна и нет лицензии MSVC, поэтому я не могу обновить его сейчас.

Есть конкретная проблема, что вы бежите от попыток построить его в VC2012?

Цитата: jackjack 13 апреля 2013 года, 2:01:58 PM

Параллельный импорт означает параллельное wallet.dat модифицирование
Я думаю, что это проблема

В самом деле. Из того, что я заметил, это вровень базы данных бумажника, что делает импорт медленно. После каждого ключевого импорта, в целях безопасности, база данных синхронизируются на диск, и по какой-то причине это занимает больше времени, когда есть несколько ключей в нем. Смотрите также https://github.com/bitcoin/bitcoin/issues/2511 .

Эта проблема исчезнет, когда мы переходим от BerkelyDB в формате бумажника дописывания только. Это на дорожной карте 0,10 / 0,11.

Привет, Джон,

Кстати, ТНХ для PMS. Я был весь клиент Bitcoin на псевдодиске так его не I / O производительности, что делает его медленно.

Дорогой, кажется, проверка импортируемого ключа плюс отсутствует поддержка многоядерных. Ключ проверка должна быть факультативной. Вместо того, чтобы писать на каждом импорте клиент может ждать скажем 60 секунд, если какие-либо больше импорта происходит или нет. Если не писать wallet.dat. Храните новые ключи в памяти, или по крайней мере установить ограничение буфера 1 МБ или около того.

Для массового импорта ключей логика коды должна быть разной. Может быть, нам нужен новый параметр massimport, чтобы справиться с этой ситуацией лучше.
Как весело тест я дайте ему поработать в течение нескольких дней, и был около одного миллиона случайных адресов в клиенте (wallet.data из около 900 МБ). Ram использования около 700 МБ без каких-либо проблем. Таким образом, основной код является стабильным, чтобы иметь дело с массивными адресами, вот хорошие новости.

VS2012 с VC или Intel компиляторов жалуются несовместимого кода. Некоторые разделы должны быть переписаны.

Цитата: PoorGirl от 17 апреля 2013 года, 4:28:08 PM

Для массового импорта ключей логика коды должна быть разной. Может быть, нам нужен новый параметр massimport, чтобы справиться с этой ситуацией лучше.
Как весело тест я дайте ему поработать в течение нескольких дней, и был около одного миллиона случайных адресов в клиенте (wallet.data из около 900 МБ). Ram использования около 700 МБ без каких-либо проблем. Таким образом, основной код является стабильным, чтобы иметь дело с массивными адресами, вот хорошие новости.

Приятно слышать

котировка

VS2012 с VC или Intel компиляторов жалуются несовместимого кода. Некоторые разделы должны быть переписаны.

Еще в тот день я уже сделал некоторые изменения, чтобы сделать его компилируется с VS2010. Однако, как никто регулярно компилировать его с одним из этих компиляторов, вероятно некоторых новых несовместимостей пробрались.
Я дам ему еще одну попытку с VS2012 экспрессом, когда я вокруг него.

3 апреля 2013, 8:52:31 PM	# 1
Бедная девушка Сообщений: 30 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Как идет его так медленно, чтобы добавить частные ключи с помощью importprivkey? На 1.8GHz машине Intel Dual Core, где bitcoind хранится на большом псевдодиска суммарная скорость составляет около 2 ключа / второй. CPU находится в режиме ожидания на 0-1%, означает, что массивное время впустую впустую. Является ли это интерфейс RPC, что так медленно? Если база данных будет работать трудно было бы показать в использовании процессора. Но нет ни одного. Для известково публичных хэши / адресов и т.д., также не является ограничивающим фактором, так как он будет отображаться в диспетчере задач. И да, я поставил Пересканировать ложь .. Я использую C # код, базовый пример здесь: Однако его с той же скоростью, чтобы просто позвонить bitcoind через cmd.exe и добавить необходимый Params для importprivkey. Поэтому его не в C # проблемы. Что-то здесь не так .. Кажется, в настоящее время единственный быстрый способ добавить ключи непосредственно wallet.dat, которая является довольно болезненной задачей закодировать под виндой ..

3 апреля 2013, 9:03:40 PM	# 2
dserrano5 Сообщения: 1848 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Получил 1806 Биткоинов Реальная история. Установите третий параметр importprivkey ложь, чтобы избежать blockchain пересканирования, то операция очень быстро. Выполните повторное сканирование только на последнем privkey вы хотите импортировать.

4 апреля 2013, 2:45:42 AM	# 3
Бедная девушка Сообщений: 30 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Здравствуй, Я сделал это уже, процитировать первый пост "И да, я поставил Пересканировать ложь .." Вместо бага поохотиться мою машину, позволяет собирать статистику. Как быстро вы можете импортировать ключи с importprevkey через JSON-RPC и имеющий полный клиент Bitcoin на Ramdisk с любыми 3 Гб / с или около скорости ввода / вывода? Позволяет составить конкуренцию импортировать 10.000 частных ключей .. Доказательство того, что я не прав, чтобы сказать, что нынешний путь клиент имеет дело с Bitcoin importprevkey так же глупо, как я думал, что BASIC изменит мир в школе, когда я был моложе клещ. Я начал: 2 ключа / сек .. Intel Dual Core 1,8 ГГц, C # код - бить это!

5 апреля 2013, 3:41:16 AM	# 4
Michail1 Сообщения: 1238 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Является ли это действительно проблема, что вам потребуется более 2-х ключей в секунду. Мне интересно, почему кто-то будет нужно импортировать 10000 ключей, не говоря уже о более. Похоже, что-то вы могли бы просто сценарий сделали к утру.

5 апреля 2013, 9:20:08 AM	# 5
Wumpus Сообщения: 812 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Это действительно странно, что это занимает так много времени, учитывая, что вы установили Пересканировать ложь. Есть ли разница в скорости между Пересканировать и выключается? Если трудно база данных работает это не обязательно проявляется в использовании процессора. Многие операции с базой данных O оценка I /, так что, возможно, проводит большую часть времени в ожидании диска.

5 апреля 2013, 9:32:30 AM	# 6
jackjack Сообщения: 1134 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Когда я использую pywallet сливаться бумажники, она занимает около 2мин 200 адресов, так что меня не шокирует Это обработка ключа, который занимает некоторое время

5 апреля 2013, 9:54:56 AM	# 7
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Это явно не так, что импорт закрытых ключей настолько медленно. Это редкая операция, так что никто не проводил много времени выяснить, где время идет. Профилирование это было бы полезным вкладом.

5 апреля 2013, 12:03:51 PM	# 8
jackjack Сообщения: 1134 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Кто-то может настроить pywallet в функции слияния бумажник и положил таймеры, чтобы найти медленную линию (s)

5 апреля 2013, 7:13:01 PM	# 9
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Я просто проверял и импортировала 20 ключей в соответствии с 100мс из командной строки (в том числе время, чтобы вилка) с bitcoind мерзавца примерно неделю назад. Я подозреваю, что вы предоставляете повторное сканирование флага в качестве метки. Из командной строки правильный вызов является: Код: bitcoind importprivkey 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx "" ложный С "" будучи на этикетке. Вознаграждение за ваши необоснованные оскорбления в другом потоке принимается по адресу в моей подписи.

5 апреля 2013, 7:35:09 PM	# 10
Wumpus Сообщения: 812 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Цитата: gmaxwell от 05 апреля 2013 года, 7:13:01 PM Я подозреваю, что вы предоставляете повторное сканирование флага в качестве метки. Это было мое подозрение, как хорошо, но из связанного кода: это выглядит как ярлык "NewKeyName" передается. Поэтому мой вопрос / ложь делает ли Пересканировать истинное значение. Я бы ожидать, что это будет гораздо медленнее, чем две клавиши в секунду с пересканирует. Цитата: gmaxwell от 05 апреля 2013 года, 7:13:01 PM Вознаграждение за ваши необоснованные оскорбления в другом потоке принимается по адресу в моей подписи.

6 апреля 2013, 8:05:36 PM	# 11
Killdozer Сообщения: 204 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? котировка Я бы ожидать, что это будет гораздо медленнее, чем две клавиши в секунду с пересканирует. И то, и также, если это правда, то процессор должен был на 100%? Если вы используете псевдодиск, есть не намного больше, чтобы замедлить его ...

10 апреля 2013, 10:25:40 PM	# 12
Бедная девушка Сообщений: 30 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Использование мода версии C # Casascius Bitcoin-адрес-Utility (https://github.com/casascius/Bitcoin-Address-Utility) Я мог бы генерировать личные ключи от случайных фразах, плюс их BTC адресов со скоростью 11 клавиш / с и 50% загрузки процессора (Intel Dual Core 1,86 ГГц, нет HT). Таким образом, должна быть около 20 клавиш / с с многопоточным кодом по сравнению с 2,8 ключей / с bitcoind с его странной 0-1% загрузкой процессора.

11 апреля 2013, 3:51:12 AM	# 13
BkkCoins Сообщения: 784 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Я подозреваю: 1. Сканирование бумажник, чтобы увидеть, если он уже в бумажнике, и / или 2. Выполнение валидности проверки, чтобы убедиться, что ключ подходит. но я не проверял код. Если вы действительно хотите знать, взглянуть на коде импорта и посмотреть, что он делает, кроме добавления его в данный бумажнике.

12 апреля 2013, 2:50:37 AM	# 14
deepceleron Сообщения: 1512 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Окна около 5x медленнее при выполнении команды RPC, чем Linux.

12 апреля 2013, 3:25:03 AM	# 15
BkkCoins Сообщения: 784 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Цитата: PoorGirl 10 апреля 2013, 10:25:40 PM Использование мода версии C # Casascius Bitcoin-адрес-Utility (https://github.com/casascius/Bitcoin-Address-Utility) Я мог бы генерировать личные ключи от случайных фразах, плюс их BTC адресов со скоростью 11 клавиш / с и 50% загрузки процессора (Intel Dual Core 1,86 ГГц, нет HT). Таким образом, должна быть около 20 клавиш / с с многопоточным кодом по сравнению с 2,8 ключей / с bitcoind с его странной 0-1% загрузкой процессора. Ммм. Генерирование вовсе не то же самое, как импортировать. Импорт представляет собой запись процесса учета / верификацию, где в качестве генерации является процессом математики. Генерация ключа из ключевой фразы является довольно быстрый хэш только процесс. Я ожидаю, генерируя использовать процессор гораздо больше, чем импортировать.

13 апреля 2013, 12:36:57 PM	# 16
Бедная девушка Сообщений: 30 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Ключевой процесс проверки должен быть факультативным в свое время дорого. Я уверен, что мои сгенерированные ключи действительны, так что я просто хочу, чтобы импортировать их без проверки. Для того, чтобы создать ключ DEP и записать его wallet.dat не дорого. Для того, чтобы увеличить скорость импорта я побежал несколько приложений importprivkey Rpc параллельно: 10 параллельных приложений = аварии через 5 мин 5 parallell приложения = авария после 12 часов, но, наконец, использование ЦП bitcoind поднялось до 50%, а скорость импорта также значительно быстрее. Подобно мое моделирование. Таким образом, кажется, что bitcoind не любит параллельную Rpc команды и получает hickup где-то. Таким образом, идеальным решением было бы: - сделать путь кода для importprivkey многопоточного везде, где это возможно (OpenMP или автоматическая с компиляторов Intel C ++) - позволяют параллельные команды входящие RPC. Если больше команд RPC приходят могут быть обработаны сохранять их в буфере и работать их позже или ответить с кодом ошибки 0 для "занятый", Я не могу скомпилировать bitcoind на Windows. Если однодневные есть рабочий проект VS2012 Я рад помочь.

13 апреля 2013, 2:01:58 PM	# 17
jackjack Сообщения: 1134 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Параллельный импорт означает параллельное wallet.dat модифицирование Я думаю, что это проблема

13 апреля 2013, 2:09:13 PM	# 18
Wumpus Сообщения: 812 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Цитата: PoorGirl 13 апреля 2013, 12:36:57 PM Я не могу скомпилировать bitcoind на Windows. Если однодневные есть рабочий проект VS2012 Я рад помочь. Создание VS2012 проекта Bitcoind должно быть довольно выполнимо (если вам не нужен графический интерфейс, Qt + MSVC несколько сложнее). Я сделал это один раз, но крайне устарели, так, вероятно, бесполезно. Тем не менее, у меня нет бегущего окна и нет лицензии MSVC, поэтому я не могу обновить его сейчас. Есть конкретная проблема, что вы бежите от попыток построить его в VC2012? Цитата: jackjack 13 апреля 2013 года, 2:01:58 PM Параллельный импорт означает параллельное wallet.dat модифицирование Я думаю, что это проблема В самом деле. Из того, что я заметил, это вровень базы данных бумажника, что делает импорт медленно. После каждого ключевого импорта, в целях безопасности, база данных синхронизируются на диск, и по какой-то причине это занимает больше времени, когда есть несколько ключей в нем. Смотрите также https://github.com/bitcoin/bitcoin/issues/2511 . Эта проблема исчезнет, когда мы переходим от BerkelyDB в формате бумажника дописывания только. Это на дорожной карте 0,10 / 0,11.

17 апреля 2013, 4:28:08 PM	# 19
Бедная девушка Сообщений: 30 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Привет, Джон, Кстати, ТНХ для PMS. Я был весь клиент Bitcoin на псевдодиске так его не I / O производительности, что делает его медленно. Дорогой, кажется, проверка импортируемого ключа плюс отсутствует поддержка многоядерных. Ключ проверка должна быть факультативной. Вместо того, чтобы писать на каждом импорте клиент может ждать скажем 60 секунд, если какие-либо больше импорта происходит или нет. Если не писать wallet.dat. Храните новые ключи в памяти, или по крайней мере установить ограничение буфера 1 МБ или около того. Для массового импорта ключей логика коды должна быть разной. Может быть, нам нужен новый параметр massimport, чтобы справиться с этой ситуацией лучше. Как весело тест я дайте ему поработать в течение нескольких дней, и был около одного миллиона случайных адресов в клиенте (wallet.data из около 900 МБ). Ram использования около 700 МБ без каких-либо проблем. Таким образом, основной код является стабильным, чтобы иметь дело с массивными адресами, вот хорошие новости. VS2012 с VC или Intel компиляторов жалуются несовместимого кода. Некоторые разделы должны быть переписаны.

17 апреля 2013, 5:46:53 PM	# 20
Wumpus Сообщения: 812 Цитировать по имени цитировать ответ	Re: Только 2 ключа / сек с добавлением importprivkey? Цитата: PoorGirl от 17 апреля 2013 года, 4:28:08 PM Для массового импорта ключей логика коды должна быть разной. Может быть, нам нужен новый параметр massimport, чтобы справиться с этой ситуацией лучше. Как весело тест я дайте ему поработать в течение нескольких дней, и был около одного миллиона случайных адресов в клиенте (wallet.data из около 900 МБ). Ram использования около 700 МБ без каких-либо проблем. Таким образом, основной код является стабильным, чтобы иметь дело с массивными адресами, вот хорошие новости. Приятно слышать котировка VS2012 с VC или Intel компиляторов жалуются несовместимого кода. Некоторые разделы должны быть переписаны. Еще в тот день я уже сделал некоторые изменения, чтобы сделать его компилируется с VS2010. Однако, как никто регулярно компилировать его с одним из этих компиляторов, вероятно некоторых новых несовместимостей пробрались. Я дам ему еще одну попытку с VS2012 экспрессом, когда я вокруг него.

Заголовок