«Нам часто в жизни не хватает друзей и доброты…»

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



Но на новой работе больше нет Microsoft Office, и хотелось бы найти нечто подобное, чтобы всякие заметки и черновики незаметно мигрировали с компьютера на компьютера.

Я знаю, что есть веб-приложение OneNote, но онлайн версия, на мой взгляд, не так удобна. Она не запоминает выбранный раздел и страницу. Версии Microsoft Office 2010 и 2013 интегрируются с онлайн версией: в них можно редактировать записную книжку, хранящуюся в облаке, но у меня дома Office 2007, и он так не умеет, к сожалению.

Расскажите, чем вы пользуетесь для хранения заметок и черновиков?

Жена и сын теперь резво гоняют в Need for Speed Underground 2, которая вышла в 2004 г. Игра прекрасно работает под управлением Windows 7 x64. Правда не идет в максимальном разрешении, пришлось уменьшить до 1200×1024, полностью убрать сглаживание (anti-aliasing), а также уменьшить детализацию мира. Но это не так страшно, хотя я думал, что мощностей моего, хоть и далеко не нового, компьютера, должно хватать.

Главная беда заключается в том, что игрушка не запоминает настройки управления. Клавиши можно поменять, но они не сохраняются, и при следующем запуске игры нужно заново настраивать управление. Странно… мне казалось, что раньше настройки управления тоже нормально сохранялись. Но тогда была Windows XP. А сейчас — Windows 7. Попробовал запускать с правами администратора — не помогло. Попробовал запустить в режиме совместимости с Windows XP — также безрезультатно.

Затем решил поискать в интернете: наверняка, не только мы играем в старые игры. Нашел обсуждение: Такая беда на Windows 7 не сохраняется управление. Конечно, для начала покричали, что Windows 7 не поддерживается, ставьте XP и будет счастье… Звучали даже аргументы, что нет папки C:\Documents and Settings\All Users\Application Data, несмотря на то, что данный путь прекрасно отображается системой в правильное место C:\ProgramData. Но не в этом суть…

В конце темы предлагалось лекарство: архив dimap.zip. Внутри архива dimap.dll, которую нужно положить в папку, где установлена игра.

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

Впрочем, магия была развеяна. Поиск по имени библиотеки dimap.dll объяснил происходящее. Библиотека dimap.dll входила в предыдущие версии Windows и была удалена из Windows Vista. Скаченная мною библиотека полностью совпадает с версией, найденной в \Windows\system32\dimap.dll из Windows XP.

Вчера я задал интересный вопрос:

«Хорошая книга, мой спутник, мой друг, с тобой интересней бывает досуг.»

Подскажите, пожалуйста, где в этом предложении подлежащее и сказуемое. Какую роль выполняет в нем слово книга?

Я сомневался…

На первый взгляд, я решил, что слова книга, спутник, друг являются подлежащими в односложных предложениях без сказуемого. Подумав еще немного, я передумал: эти слова являются обращением. В то же время обращения не являются членами предложения, то есть они — ни подлежащее, ни сказуемое.

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

Подтверждения своей мысли я практически не нашел… В Twitter был всего один ответ, от @Rustenity, и он сказал то же самое:

@aylivex "книга" здесь является обращением, я думаю...

— Rustenity (@Rustenity) October 1, 2013

Затем сегодня утром wotton_henry подтвердил мое мнение:

Подлежащее — досуг. Сказуемое — бывает интересней. Книга — обращение, не является членом предложения.

спасибо zheka79

Спасибо всем, кто ответил.

«Хорошая книга, мой спутник, мой друг, с тобой интересней бывает досуг.»

Подскажите, пожалуйста, где в этом предложении подлежащее и сказуемое. Какую роль выполняет в нем слово книга?

Read it in English

В очередной раз пришлось разбираться с ошибками установки библиотек Visual C++ 2005 x64. (В прошлый раз пришлось бороться с тем, что компоненты приложения ссылались на разные версии C++ runtime. Именно тогда в инсталляторе стали использоваться merge-модули.)

В этот раз на системах Windows 7 и Windows Server 2008 R2. Во время установки возникает следующая ошибка:

Текст сообщения:

An error occured during the installation of assembly component {844EFBA7-1C24-9382-A01F-C8B3B9A1E18E}.
HRESULT: 0x80073715.

В подробном логе, полученном с помощью (msiexec /i prod.msi /l*v msi.log), нашлись следующие записи:

MSI (s) (E0:E0) [15:43:58:875]: Assembly Error:The identities of the manifests are identical but their contents are different.
MSI (s) (E0:E0) [15:43:58:875]: Note: 1: 1935 2:
{844EFBA7-1C24-93B2-A01F-C8B3B9A1E18E} 3: 0x80073715 4: IAssemblyCacheItem 5:
Commit 6:
Microsoft.VC80.CRT,type="win32",version="8.0.50727.4053",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="amd64"
MSI (s) (E0:E0) [15:43:58:875]: Assembly Error (sxs): Please look into
Component Based Servicing Log located at -121510792ndir\logs\cbs\cbs.log to get
more diagnostic information.
Error 1935. An error occured during the installation of assembly component
{844EFBA7-1C24-93B2-A01F-C8B3B9A1E18E}. HRESULT: 0x80073715. assembly
interface: IAssemblyCacheItem, function: Commit, assembly name:
Microsoft.VC80.CRT,type="win32",version="8.0.50727.4053",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="amd64"

Лог файл %winndir%\logs\cbs\cbs.log не предоставил много больше информации, хотя в нем содержался мнемонический код ошибки: STATUS_SXS_MANIFEST_IDENTITY_SAME_BUT_CONTENTS_DIFFERENT. Этот код ошибки означает, что в системе уже есть сборка с таким же identity, что и устанавливаемая, и их версии тоже совпадают, но при этом устанавливаемые файлы отличаются.

На доступных мне машинах я не смог воспроизвести проблему: успешно устанавливается и работает. В процессе исследований выяснилось, что на проблемных машинка уже установлена сборка (assembly) Microsoft Visual C++ 2005 x64 Runtime.

Установил у себя из vcredist_x64.exe. После этого установка продукта стала завершаться с ошибкой.

Провел я и обратный эксперимент: на чистую машинку сначала установил наш продукт, а затем VC++ 2005 runtime. В результате установка vcredist_x64.exe завершилась с такой же ошибкой:

Текст сообщения:

Product: Microsoft Visual C++ 2005 Redistributable (x64) -- Error 1935.An error occurred during the installation of assembly 'Microsoft.VC80.CRT,type="win32",version="8.0.50727.4053",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="amd64"'. Please refer to Help and Support for more information. HRESULT: 0x80073715. assembly interface: IAssemblyCacheItem, function: Commit, component: {844EFBA7-1C24-93B2-A01F-C8B3B9A1E18E}

Решил сравнить содержимое папок C:\Windows\winsxs\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4053 после установки из merge-модуля и после vcredist_x64.exe. Сборка содержит три файла: msvcm80.dll, msvcp80.dll, msvcr80.dll. Версии и размеры этих файлов совпадают в обоих вариантах установки. Но все равно два файла из набора отличаются друг от друга. Я выяснил, что отличаются они временем цифровой подписи: В merge-модулях библиотеки подписаны 12 июля 2009 г. в 11 часов, а в vcredist_x64.exe 12 июля 2009 г. в 6 часов:

На системах с Windows XP и Windows Server 2003 подобная разница не приводила к ошибке. А на более новых Windows 7 и Windows Server 2008 R2 приводит к ошибке.

В Microsoft Connect эта проблема описана: 8.0.50727.4053 x64 CRT merge modules fails to install on x64 but ok on x86. Это же сообщение можно найти на форуме MSDN. Вопрос помечен как решенный, но ответ какой-то бессодержательный и невразумительный. В сообщении есть ссылка на другое описание такой же проблемы в Microsoft Connect.

И у меня тоже никакого решения для преодоления данной трудности.
Ясно одно, что Visual C++ 2005 x64 runtime нельзя установить одновременно и из merge-модулей, и из vcredist_x64.exe, чего быть не должно.

С 32 битной (x86) версией таких проблем нет: всё прекрасно работает.

На прошлой неделе столкнулся с интересной проблемой DLL Hell'а.

Чтобы решить проблему с библиотеками, в Windows XP появился механизм side-by-side assemblies. В системе может быть установлено несколько версий одной и той же библиотеки, а каждое приложение должно явным образом указать, какую версию следует загрузить. Такой механизм явного объявления зависимостей устраняет ошибки из-за загрузки несовместимой версии библиотеки.

Но не все так гладко… Начиная с Visual Studio 2005, библиотеки С++ runtime поставляются в виде side-by-side assemblies, а компилятор/линкер автоматически создают manifest файл, в котором указываются эти зависимости.

Проблемы возникают, когда приложение использует DLL, которые собираются не из исходного кода. Например, если приложение и используемые библиотеки были откомпилированы разными версиями Visual Studio, в системе должны будут находится две (или даже больше) разных версий C++ runtime.

Вот именно с такой проблемой я и столкнулся. Сначала обнаружилось, что у нас две зависимости: от версии 8.0.50608.0 и от 8.0.50727.762. А через несколько дней среди зависимостей вдруг появилась еще и третья версия 8.0.50727.4053.

Раньше библиотеки Visual C++ вместе с манифестом лежали в папке с остальными библиотеками, и всё работало. (То есть они использовались как private assembly.) Недавно выяснилось впрочем, что не совсем всё работало: обнаружилось, что на тестовых машинах были установлены библиотеки версии 8.0.50727.42. А если вдруг их не оказывалось, то ничего не запускалось.

Две разных версии assembly не могут одновременно находится в папке с приложением, потому что файлы называются одинаково. Как обойти это, описано в статье A solution to two references to different versions of CRT, MFC, ATL in one application manifest file. Workaround #2 не помогал, потому что зависимости росли не из EXE-файла, а из DLL. В комментариях нашлось решение и для DLL, которое более подробно описано здесь. После добавления файликов <dll-name>.2.config приложение заработало.

Но с появлением зависимости от третьей версии, которая появилась после установки обновления, пришлось бы создавать такие файлы почти для каждой DLL-библиотеки, а их не мало. В итоге, чтобы жизнь была проще, был выбран первый вариант решения: использование Merge-модулей, тем более для установки уже использовался Windows Installer. Merge-модули устанавливают не только сами библиотеки, но и policy-файл, который «перенаправляет» предыдущие версии на новую версию. Таким образом, поставка всего одной версии библиотек и установка глобальной политики перенаправления версий решило все проблемы с зависимостями и избавило от создания кучи config-файлов с одинаковым содержанием.

На эти исследования пришлось потратить почти два дня, зато теперь в арсенале имеются новые знания.