Re[11]: Как избежать проблем с виртуализацией? - Shareware и бизнес

При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются разнообразные глюки. Я выбрал простое решение — на сайте программы написал, что не рекомендую инсталлировать её под этими Windows в этот каталог. Есть ли более удачное и при этом простое решение (для чайника вроде меня, пишущего шаровару на Delphi7)?

Здравствуйте, Khimik, Вы писали:

K> При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются разнообразные глюки. Я выбрал простое решение — на сайте программы написал, что не рекомендую инсталлировать её под этими Windows в этот каталог. Есть ли более удачное и при этом простое решение (для чайника вроде меня, пишущего шаровару на Delphi7)?

Проблемы не должны быть вызваны виртуализацией.

Здравствуйте, Khimik, Вы писали:

K> При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются разнообразные глюки. Я выбрал простое решение — на сайте программы написал, что не рекомендую инсталлировать её под этими Windows в этот каталог. Есть ли более удачное и при этом простое решение (для чайника вроде меня, пишущего шаровару на Delphi7)?

я тоже прошу не ставить проги в "c:\program files"
У меня дорогой софт для девелоперов, так что они все проглатывают

Здравствуйте, Khimik, Вы писали:

K> При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются

Манифест надо нормальный прилинковывать
для Vista+ нужен блок:

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>

или с
level="highestAvailable"

Можно после блока dependency воткнуть

Иначе включается виртуализация со всеми сопутсвующими "удовольствиями".
В 7 Делфи этог автоматом нет, надо ресурс делать самому и прилинковывать к проге.
в поздних делфях это все уже есть.

А вообще МСДН надо курить на эту тему

Здравствуйте, Khimik, Вы писали:

K> При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются разнообразные глюки. Я выбрал простое решение — на сайте программы написал, что не рекомендую инсталлировать её под этими Windows в этот каталог. Есть ли более удачное и при этом простое решение (для чайника вроде меня, пишущего шаровару на Delphi7)?

А какие там могут быть глюки? Либо руки кривые, либо данные там храните, что не рекомендуется аж черте с каких годов.

Здравствуйте, Khimik, Вы писали:

K> При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются разнообразные глюки. Я выбрал простое решение — на сайте программы написал, что не рекомендую инсталлировать её под этими Windows в этот каталог. Есть ли более удачное и при этом простое решение (для чайника вроде меня, пишущего шаровару на Delphi7)?

Дык это наверное проблема с UAC, а не с виртуализацией?

Здравствуйте, MikePetrichenko, Вы писали:

MP>А какие там могут быть глюки? Либо руки кривые, либо данные там храните, что не рекомендуется аж черте с каких годов.

Их там есть море:
— пишем в HKLM пишется без проблем. Но данные видны только из прог которые под виртуализацией
— аналогичные эффекты если какие-либо настройки или именяемые данные лежат в Program Files.
— то же про папку Windows.
— без проблем могу записать что либо в реестр или папку, куда мне доступ априори запрещен. Но с тем же эффектом. Изменения видны только под виртуализацией и не видны в нормальных прогах.

я в свое время чуть мозгами не двинулся пытаясь понять что за голимые эффекты

Потом уже въехал как это все делается.

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

Здравствуйте, drVanо, Вы писали:

V>Дык это наверное проблема с UAC, а не с виртуализацией?

Естественно такие эффекты возникают только с включенным UAC и в прогах без соответсвующего манифеста.
UAC можно и выключить. Но большинство юзеров этого делать не будет. А многим еще и объяснять долго нужно как это сделать.

К тому же нафиг нужны пляски с бубном, если проблема решеается прикручиванием нужного манифеста?

Здравствуйте, drpops, Вы писали:

V>>Дык это наверное проблема с UAC, а не с виртуализацией?

D>Естественно такие эффекты возникают только с включенным UAC и в прогах без соответсвующего манифеста.
D>UAC можно и выключить. Но большинство юзеров этого делать не будет. А многим еще и объяснять долго нужно как это сделать.

D>К тому же нафиг нужны пляски с бубном, если проблема решеается прикручиванием нужного манифеста?

В "C:\Program Files\..." вообще не рекомендуется ничего писать. Храните свои настройки в %APPDATA%и и голову пользователям не морочьте.

Здравствуйте, Khimik, Вы писали:

K> При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются разнообразные глюки. Я выбрал простое решение — на сайте программы написал, что не рекомендую инсталлировать её под этими Windows в этот каталог. Есть ли более удачное и при этом простое решение (для чайника вроде меня, пишущего шаровару на Delphi7)?

Подписываюсь под всеми сообщениями выше.
Все эти проблемы решаются. Пользовательские данные храним в Users, рабочие данные программы — в
ApplicationData. В реестр пишем только в HKEY_CURRENT_USER. exe-шники приложения снабжаем
манифестами с trustInfo, compatibility и dpiAware. Не используем интерактивные сервисы, планируем
работу приложения в терминальных и многопользовательских сессиях, все тестирование проводится под
учетными записями из группы "Пользователи" и "Гости". И не имеем в итоге никаких проблем совместимости.

Здравствуйте, drVanо, Вы писали:

V>В "C:\Program Files\..." вообще не рекомендуется ничего писать. Храните свои настройки в %APPDATA%и и голову пользователям не морочьте.

С %APPDATA% тоже не так все просто. А если если нужно бы из под любого юзера эти данные были видны и могли редактироватся?
Есть еще %ProgramData% но там с правами доступа приколы. Писать в файл может только юзер-владелец по дефолту. А создать может любой. Т.е. кто первый занял — того и тапки

Конечно если прога работает только в пределах локальной сессии никак не затрагивая систему и других юзеров, то профиль пользователя — наше все.

Здравствуйте, Khimik.

Грубо говоря, Вам нужно подключить ко всем исполняемым файлам специальные манифесты.
Манифест — это просто текстовый ресурс в формате XML, который, кстати, может лежать
рядом с исполняемым файлом. Его содержимое может быть примерно таким:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<assembly
    xmlns="urn:schemas-microsoft-com:asm.v1"
    manifestVersion="1.0">

    <assemblyIdentity
        type="win32"
        name="Company.Product.Module"
        version="1.0.0.0"
        processorArchitecture="x86">
    </assemblyIdentity>

    <description>My Cool Module</description>

    <dependency>
        <dependentAssembly>
            ...
        </dependentAssembly>
    </dependency>

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel
                    level="asInvoker"
                    uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo>

    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
        </application>
    </compatibility>

    <application xmlns="urn:schemas-microsoft-com:asm.v3">
        <windowsSettings>
            <dpiAware
                xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
        </windowsSettings>
    </application>

</assembly>

<assemblyIdentity> нужен для идентификации исполняемого файла или динамической библиотеки.
Это обычная метаинформация, но иногда она может играть важную роль при выборе
нужной версии сборки.

<description> опционален.

В <dependency> прописываются зависимости от различных общих и частных сборок,,
установленных на компьютере, от конкретных их версий (это один из механизмов разруливания
проблемы "Dll Hell"). Типичный пример — зависимость от библиотеки Common-Controls шестой версии.

<trustInfo> определяет, какие уровень прав требуется для корректной работы приложения.
Варианты: asInvoker — запуск с правами пользователя, highestAvailable — максимально возможный
уровень (пользователю будет показано окно с предложением ввести имя пользователя и пароль),
requireAdministrator — приложению требуются администраторские права (снова будет запрос UAC).
Подсказка: highestAvailable и requireAdministrator большинству нормальных приложений почти
никогда не нужны.

<compatibility> нужен приложениям на Windows 7 и выше, которые хотят "включить" все заплатки,
выпущенные после выхода Vista, и работать напрямую, без "эмуляции" поведения Vista.
Например, есть известный глюк в GetOverlappedResult, который починили только в Windows 7,
однако для совместимости оставили возможность сохранить старое поведение этой функции.

<dpiAware> показывает, что приложение будет правильно отображаться на настройках с высоким DPI.
Без этой опции все GUI-шные элементы на таких настройках будут просто и тупо растянуты.

Такой файл манифеста нужно сохранить (в UTF-8) и включить в exe как ресурс.
Тип ресурса — 24, ID — 1 (для dll ID равен 2). Либо можно положить данный файл прямо рядышком с
exe-файлом, присвоив ему соответствующее имя. Например, для myprogram.exe манифест должен
называться myprogram.exe.manifest.

После описанных манипуляций загрузчик Windows будет воспринимать данный exe как полностью
совместимый с Vista/Windows 7 и никакая виртуализация задействована не будет.
Это, разумеется, потребует полного отказа от запись в системные папки и разделы реестра, а
также соблюдения всех остальных, документированных в MSDN, "норм поведения".

Здравствуйте, drpops, Вы писали:

D>С %APPDATA% тоже не так все просто. А если если нужно бы из под любого юзера эти данные были видны и могли редактироватся?

...\All users\

Здравствуйте, v6, Вы писали:

v6>Здравствуйте, drpops, Вы писали:

D>>С %APPDATA% тоже не так все просто. А если если нужно бы из под любого юзера эти данные были видны и могли редактироватся?

v6>...\All users\
...\All users\ это не папка, если Вы еще не знаете

Это только ссылка на C:\ProgramData со всеми пиколами (см пред. пост)

Здравствуйте, drpops, Вы писали:

D>Это только ссылка на C:\ProgramData со всеми пиколами (см пред. пост)

SetSecurityInfo помогает иногда от таких приколов с владельцем и правами доступа.
Хотя коллективная запись в один файл — это все равно неразрешимая обычными
методами проблема.

Здравствуйте, drpops, Вы писали:

D>я в свое время чуть мозгами не двинулся пытаясь понять что за голимые эффекты

Потом уже въехал как это все делается.

Читаем правила поведения программ под Windows (Windows Application Design Guide). Там черным по-английски (а есть и книга написанная черным по-русски, от MS Press) прописано, что, где и как хранить. Чтобы не было потом мучительно больно и не плакать, потом, по форумам от того, что программа криво спроектирована.

По поводу "AllUsers не папка". Курить SHGetSpecialFolderLocation и аналогичное. Там же есть ID системных папок, в том числе и AllUsers.

D>Так что лучше делать все как положено и не заниматься изобретением велосипеда

Вот это поддерживаю! Это архиправильно!

Здравствуйте, vladrsdn, Вы писали:

V>Здравствуйте, Khimik, Вы писали:

K>> При установке некоторых программ (в том числе моей) под Windows Vista / Windows7 в "C:\Program Files\..." из-за виртуализации начинаются разнообразные глюки. Я выбрал простое решение — на сайте программы написал, что не рекомендую инсталлировать её под этими Windows в этот каталог. Есть ли более удачное и при этом простое решение (для чайника вроде меня, пишущего шаровару на Delphi7)?

V>я тоже прошу не ставить проги в "c:\program files"
V>У меня дорогой софт для девелоперов, так что они все проглатывают

Странные у вас девелоперы которые терпят такую лажу

P.S. Все нужно ставить не спрашивая в корень диска C:

"okman" <90691@users.rsdn.ru> wrote in message news:4709191@news.rsdn.ru...
> SetSecurityInfo помогает иногда от таких приколов с владельцем и правами доступа.
> Хотя коллективная запись в один файл — это все равно неразрешимая обычными
> методами проблема.

Хм? Решается при установке в Inno Setup одной строчкой:

[Dirs]
Name: {commonappdata}\CompanyName\AppName; Permissions: everyone-modify;

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, wellwell, Вы писали:

W>Хм? Решается при установке в Inno Setup одной строчкой:
W>...

Это да, но остается еще одна проблема — сериализация доступа.
Например, когда два или больше пользователей одновременно перезаписывают один и
тот же файл внутри All Users, после чего его состояние становится неконсистентным.
Хотя это все тоже решается всякими мьютексами/семафорами. Правда, для этого
они должны быть снабжены префиксом Global, и чтобы их могли открывать пользователи с
разными правами, все равно придется звать SetSecurityInfo на этих объектах

> Это да, но остается еще одна проблема — сериализация доступа.
> Например, когда два или больше пользователей одновременно перезаписывают один и
> тот же файл внутри All Users, после чего его состояние становится неконсистентным.
> Хотя это все тоже решается всякими мьютексами/семафорами. Правда, для этого
> они должны быть снабжены префиксом Global, и чтобы их могли открывать пользователи с
> разными правами, все равно придется звать SetSecurityInfo на этих объектах

Вообще-то есть такая штука как блокировки. Я понимаю, что простые решения некошерны по МС, но все же.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Вообще-то есть такая штука как блокировки. Я понимаю, что простые решения некошерны по МС, но все же.

Если речь про LockFile(Ex), то это не поможет, если файлов два и больше, и требуется
перезаписать их в рамках единой транзакции.

Здравствуйте, okman, Вы писали:

O>Это да, но остается еще одна проблема — сериализация доступа.
O>Например, когда два или больше пользователей одновременно перезаписывают один и
O>тот же файл внутри All Users, после чего его состояние становится неконсистентным.
O>Хотя это все тоже решается всякими мьютексами/семафорами. Правда, для этого
O>они должны быть снабжены префиксом Global, и чтобы их могли открывать пользователи с
O>разными правами, все равно придется звать SetSecurityInfo на этих объектах

Эй, ребята, а вам не кажется, что коли речь заходит о многопользователях, консистентности и транзакциях, то стоит уже взять нормальную настоящую СУБД? Заодно не будет проблем, если завтра All Users уедет на сетевую шару в домене.

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Khimik.

O>Грубо говоря, Вам нужно подключить ко всем исполняемым файлам специальные манифесты.
O>Манифест — это просто текстовый ресурс в формате XML, который, кстати, может лежать
O>рядом с исполняемым файлом. Его содержимое может быть примерно таким:
O>

O><?xml version="1.0" encoding="utf-8" standalone="yes"?>

O><assembly
O>    xmlns="urn:schemas-microsoft-com:asm.v1"
O>    manifestVersion="1.0">

O>    <assemblyIdentity
O>        type="win32"
O>        name="Company.Product.Module"
O>        version="1.0.0.0"
O>        processorArchitecture="x86">
O>    </assemblyIdentity>

O>    <description>My Cool Module</description>

O>    <dependency>
O>        <dependentAssembly>
O>            ...
O>        </dependentAssembly>
O>    </dependency>

O>    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
O>        <security>
O>            <requestedPrivileges>
O>                <requestedExecutionLevel
O>                    level="asInvoker"
O>                    uiAccess="false"/>
O>            </requestedPrivileges>
O>        </security>
O>    </trustInfo>

O>    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
O>        <application>
O>            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
O>            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
O>        </application>
O>    </compatibility>

O>    <application xmlns="urn:schemas-microsoft-com:asm.v3">
O>        <windowsSettings>
O>            <dpiAware
O>                xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
O>        </windowsSettings>
O>    </application>

O></assembly>
O>

O><assemblyIdentity> нужен для идентификации исполняемого файла или динамической библиотеки.
O>Это обычная метаинформация, но иногда она может играть важную роль при выборе
O>нужной версии сборки.

O><description> опционален.

O>В <dependency> прописываются зависимости от различных общих и частных сборок,,
O>установленных на компьютере, от конкретных их версий (это один из механизмов разруливания
O>проблемы "Dll Hell"). Типичный пример — зависимость от библиотеки Common-Controls шестой версии.

O><trustInfo> определяет, какие уровень прав требуется для корректной работы приложения.
O>Варианты: asInvoker — запуск с правами пользователя, highestAvailable — максимально возможный
O>уровень (пользователю будет показано окно с предложением ввести имя пользователя и пароль),
O>requireAdministrator — приложению требуются администраторские права (снова будет запрос UAC).
O>Подсказка: highestAvailable и requireAdministrator большинству нормальных приложений почти
O>никогда не нужны.

O><compatibility> нужен приложениям на Windows 7 и выше, которые хотят "включить" все заплатки,
O>выпущенные после выхода Vista, и работать напрямую, без "эмуляции" поведения Vista.
O>Например, есть известный глюк в GetOverlappedResult, который починили только в Windows 7,
O>однако для совместимости оставили возможность сохранить старое поведение этой функции.

O><dpiAware> показывает, что приложение будет правильно отображаться на настройках с высоким DPI.
O>Без этой опции все GUI-шные элементы на таких настройках будут просто и тупо растянуты.

O>Такой файл манифеста нужно сохранить (в UTF-8) и включить в exe как ресурс.
O>Тип ресурса — 24, ID — 1 (для dll ID равен 2). Либо можно положить данный файл прямо рядышком с
O>exe-файлом, присвоив ему соответствующее имя. Например, для myprogram.exe манифест должен
O>называться myprogram.exe.manifest.

O>После описанных манипуляций загрузчик Windows будет воспринимать данный exe как полностью
O>совместимый с Vista/Windows 7 и никакая виртуализация задействована не будет.
O>Это, разумеется, потребует полного отказа от запись в системные папки и разделы реестра, а
O>также соблюдения всех остальных, документированных в MSDN, "норм поведения".
Во! Гутное разъяснение!

А где вообще подробнее почитать про эти манифесты? Что куда, зачем и сколько? А то были совершенно другого плана странные проблемы в Висте\7 (в основном аккурат проблемы про CommonControls), и приходится медитировать методом тыка. А хотелось бы ясности хоть какой-то... Какие XML-теги на что влияют и.т.д.

Здравствуйте, okman, Вы писали:

O>Если речь про LockFile(Ex), то это не поможет, если файлов два и больше, и требуется
O>перезаписать их в рамках единой транзакции.

Тогда делаете, как было сделано в том же Paradox: один файл для блокировок. Его и пытаетесь захватить. Захватили — меняем все остальные (их лочить не нужно). Ну и FILE_SHARE_READ не забываем. Или FILE_SHARE_DENY (или как там?).

P.S. Прав был Спольски. Без знания основ нефиг начинать формочки клепать.

> G>Вообще-то есть такая штука как блокировки. Я понимаю, что простые решения некошерны по МС, но все же.
>
> Если речь про LockFile(Ex), то это не поможет, если файлов два и больше, и требуется
> перезаписать их в рамках единой транзакции.

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

И вообще, ТС не дал достаточно информации, что бы что-то ему корректно подсказать.

Posted via RSDN NNTP Server 2.1 beta

> Эй, ребята, а вам не кажется, что коли речь заходит о многопользователях, консистентности и транзакциях, то стоит уже взять нормальную настоящую СУБД? Заодно не будет проблем, если завтра All Users уедет на сетевую шару в домене.

И поднимать сервер? Если бы он подробнее написал чего хочет.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Carc, Вы писали:

C>А где вообще подробнее почитать про эти манифесты? Что куда, зачем и сколько? А то были совершенно другого плана странные проблемы в Висте\7 (в основном аккурат проблемы про CommonControls), и приходится медитировать методом тыка. А хотелось бы ясности хоть какой-то... Какие XML-теги на что влияют и.т.д.

Практически вся информация, на удивление, лежит здесь — http://msdn.microsoft.com/en-us/library/windows/desktop/aa375365(v=vs.85).aspx и здесь — http://msdn.microsoft.com/en-us/library/windows/desktop/aa375190(v=vs.85).aspx
Для unmanaged-вещей в основном нужны сведения только по Application Manifests и Assembly Manifests.
Про High DPI там же, неподалеку — http://msdn.microsoft.com/library/dd464646.aspx
Вот информация про элемент <compatibility> — http://msdn.microsoft.com/en-us/library/dd371711(v=vs.85).aspx
И в сети еще ходит PDF под названием v7dev.pdf — "Обеспечение совместимости приложений в Windows Vista и
Windows 7", рекомендую найти и прочесть.

Здравствуйте, grosborn, Вы писали:

G>Вообще-то для единой транзакции по нескольким файловым операциям совсем не нужно создавать сервер транзакций, не говоря уже о том что зачастую транзакция не нужна или можно обойтись другими алгоритмами.

Да если уже на то пошло, для обсуждаемой задачи (сериализация доступа к файлу) не нужны ни базы
данных (ну разве что какая-нибудь SQLite), ни серверы транзакций. Вполне сойдет и LockFileEx.
Просто те же Win32-мьютексы дают чуть больше возможностей. Например, если один из пишущих
процессов свалится где-нибудь посреди перезаписи, этот факт легко отследить — WaitForSingleObject
вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.

G>Ты проявляешь иногда поразительно глубокие знания, но в то же время они у тебя, как это по русски сказать, до такой же степени фрагментарны что ли, не позволяют тебе видеть простых и логичных вещей. Я сначала не мог понять почему, но кажется догадываюсь — результат командной работы.

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

> вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.

Не работает при сбоях.
Давно уже отработан простой и надежный транзакционный подход с использованием локов или чуть сложнее в целях производительности с журналированием. Только вот ввиду доведения до ума всяких sqlite и sql ce уже редко применяется, производительность не на первом месте. ТС может быть проще поднять сервис с БД и не мучиться. Несколько элегантных кликов мышой и оно работает прямо из коробки.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

>> вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.

G>Не работает при сбоях.

Заинтригован до мозга костей. А можно чуток подробнее ?

>>> вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.
>
> G>Не работает при сбоях.
>
> Заинтригован до мозга костей. А можно чуток подробнее ?

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Не сохраняется между сеансами работы компьютера.

Нужный механизм не очень-то сложно прикрутить.

Например:

1. Захватываем глобальный мьютекс.
2. Делаем бэкап файлов, подлежащих перезаписи.
3. Устанавливаем где-нибудь в реестре или в отдельном файле специальный бит.
Это значит, что операция началась. Бит нужно сразу сбросить на диск (FlushFileBuffers/
RegFlushKey).
4. Спокойно перезаписываем файлы.
5. Сбрасываем бит.
6. Освобождаем мьютекс.

Системный сбой на стадиях 1-3 или 5-6 не страшен, так как файлы либо ЕЩЕ не перезаписаны,
либо УЖЕ перезаписаны. Сбой на стадии 4 тоже не опасен, так как при следующем запуске
приложения оно будет знать, что следует читать файлы из резервного хранилища, так как
бит операции не был сброшен.

Нет, все не то. Сложно, некрасиво, неуниверсально, ненадежно. Локи чем хороши, тем что решение отлажено можно сказать поколениями. И методом ошибок и пинков, с локами научили работать большинство программистов корректно. Хотя еще встречаются иногда в линуксах или виртуалках с ними проблемы, но это на уровне признанных багов. А так они работают корректно почти везде.
Твой подход, к примеру, не будет работать если будет доступ к общим данным по сети.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Нет, все не то. Сложно, некрасиво, неуниверсально, ненадежно.

На счет "сложно" и "некрасиво" — можно опустить.
По поводу "неуниверсально" и особенно "ненадежно" — пожалуйста, аргументы в студию.

G>Твой подход, к примеру, не будет работать если будет доступ к общим данным по сети.

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

> Два компьютера в сети, на обоих запущена программа, использующая общий файл настроек из
> сетевой шары ? Извини, но я тогда тоже могу придумать еще более извращенный сценарий.

Ну здрасте. Ни разу не запускал программы с сетевой шары? Только корректно проинсталлированные? Если мы работаем с общим файлом, нельзя закладываться на то, что он будет строго в определенном месте на диске.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MikePetrichenko, Вы писали:

D>>я в свое время чуть мозгами не двинулся пытаясь понять что за голимые эффекты

Потом уже въехал как это все делается.

MP>Читаем правила поведения программ под Windows (Windows Application Design Guide). Там черным по-английски (а есть и книга написанная черным по-русски, от MS Press) прописано, что, где и как хранить.
Маленкая поправочка: я на эти голимые эффекты наткунулся и питался въехать когда тока-тока бета Висты вышла.
Уже потом и букварь почитал и у умныхлюдей спросил.

MP>По поводу "AllUsers не папка". Курить SHGetSpecialFolderLocation и аналогичное. Там же есть ID системных папок, в том числе и AllUsers.
Да SHGetSpecialFolderLocation выдает AllUsers. И туда можно зайти и там что-то написать. Но (сюрприз) это токлько ссылка на ProgramData. То что мы напишем в AllUsers автоматом появляется ProgramData и наоборот. В FAR-е это хорошо видно что это не папка, а ссылка. В проводнике ProgramData вообще скрыта по умолчанию.
Ссылка сделана скорее всего для совмесимости с пред. версиями Винды.

D>>Так что лучше делать все как положено и не заниматься изобретением велосипеда

MP>Вот это поддерживаю! Это архиправильно!

Здравствуйте, drpops, Вы писали:

D>Маленкая поправочка: я на эти голимые эффекты наткунулся и питался въехать когда тока-тока бета Висты вышла.
D>Уже потом и букварь почитал и у умныхлюдей спросил.

Эти рекомендации (букварь) были еще со времен Win 95. И там точно расписано: что, где, как и когда хранить. Куда DLL запихивать, для чего Common Files нужна и много, много другой интересной информации. Читали бы, не нужно было бы "въезжать" на Vista.

D>Да SHGetSpecialFolderLocation выдает AllUsers. И туда можно зайти и там что-то написать. Но (сюрприз) это токлько ссылка на ProgramData. То что мы напишем в AllUsers автоматом появляется ProgramData и наоборот. В FAR-е это хорошо видно что это не папка, а ссылка. В проводнике ProgramData вообще скрыта по умолчанию.
D>Ссылка сделана скорее всего для совмесимости с пред. версиями Винды.

Для приложения это абсолютно не важно. Сегодня — ProgramDara, завтра — ключ в реестре, послезавтра — так всеми любимое облачное хранилище. Для этого (чтобы приложению было фиолетово и оно работало везде) и есть SHGetSpecialFolderPath и прочее. Т. е. по ID Special Folder получаете путь к ней и работаете. Кстати, в Win 7 не только AllUsers ссылка — там их куча. А если задача стоит сделать результат работы (файл) видимым пользователю — пишем Shared Documents (Общие документы). Если что — это тоже ссылка, но она видна в проводнике.

Здравствуйте, grosborn, Вы писали:

G>Ну здрасте. Ни разу не запускал программы с сетевой шары? Только корректно проинсталлированные? Если мы работаем с общим файлом, нельзя закладываться на то, что он будет строго в определенном месте на диске.

Похоже, пора мне переходить от защиты к нападению.

Во-первых, речь шла о файле с общими данными, расположенном в глубинах Users\Public или ProgramData.
Расшаривать содержимое папки ProgramData немного странновато, тебе не кажется ?
Ну даже если так, если мы храним общий файл данных на шаре, чем здесь блокировки (LockFileEx)
помогут в плане обеспечения атомарности и консистентности ?

Смотри — есть программа, которая использует файл settings.ini, расположенный на сетевой шаре.
И в один момент на разных компьютерах запущено несколько экземпляров данной программы, причем все они
юзают settings.ini, то на чтение, то на запись. Допустим, одна из копий программы лочит файл, затем
начинает наполнять его новым содержимым. Вдруг, по какой-то внешней причине, доступ в сеть компьютера,
который пишет в файл, неожиданно обрывается. Начало файла наполнено новыми данными, конец — старыми.
Насколько я помню, когда залочивший файл процесс отваливается, ОС сама разлочивает его и делает
доступным другим процессам. Все, получаем неконсистентные данные. При этом то, что файл лежит где-то
на шаре, не имеет в данном примере никакого значения — процесс просто может неожиданно завершиться
из-за ошибки (например, в другом потоке), и состояние файла останется противоречивым.
И новый процесс, который ждет своей очереди на чтение settings.ini, никак не будет уведомлен о
том, что произошла критическая ошибка. Я не понимаю, хоть убей, чем и как здесь помогут блокировки ?

Далее. Ты пишешь, что решение с мьютексами неуниверсально.
Возражаю. Его можно использовать не только с файлами, но и с реестром, да хоть слать данные
куда-нибудь по HTTP, а сам алгоритм останется неизменным — захват мьютекса, бэкап, установка
флага, перезапись, сброс флага, освобождение мьютекса. Лочить же можно только файлы.

По поводу сложности.
Для тривиальных случаев решение, использующее легкие обертки над Win32 API, укладывается в
несколько десятков строк кода. С "фишками" — в пару сотен строк. При этом код практически
линейный, без ветвлений, в один поток. Ну и что здесь сложного ? Это, по сути, день работы +
день тестирования. Ну еще, может быть, потребуется локализовать некоторые сообщения об ошибках,
но это уже к теме сильного отношения не имеет.

Аргументов по поводу ненадежности (шара не в счет, поскольку LockFileEx тоже не лучше, если
только ты не докажешь обратное) и неуниверсальности я пока не увидел.

Поэтому не нужно писать про фрагментарность знаний, про "извращенное MC мышление" и т.д.
Хотя в этом есть доля истины, потому что я стараюсь хватать знания жадно, а не ждать,
пока они ко мне сами придут.

И еще. У тебя какая-то язвительная манера вести разговор. Складывается впечатление, что
ты задолго до разгорания спора пытаешься от чего-то отбиваться или что-то доказывать — не знаю.
Лично у меня нет желания вступать в какие-то "прения" и я уважаю тебя хотя бы как собеседника.
Если я в чем-то неправ и мне это доказывают (аргументированно!), я легко признаю свою неправоту.
И готов буду признать и в этот раз, если аргументы последуют.

Здравствуйте, MikePetrichenko, Вы писали:

MP>Здравствуйте, drpops, Вы писали:

D>>Маленкая поправочка: я на эти голимые эффекты наткунулся и питался въехать когда тока-тока бета Висты вышла.
D>>Уже потом и букварь почитал и у умныхлюдей спросил.

MP>Эти рекомендации (букварь) были еще со времен Win 95. И там точно расписано: что, где, как и когда хранить. Куда DLL запихивать, для чего Common Files нужна и много, много другой интересной информации. Читали бы, не нужно было бы "въезжать" на Vista.
Угу, угу. А еще со времен вин95 были рекомендации класть все ДЛЛ в %SYSTEM%, а мы не читали этих рекомендаций и теперь не приходится въезжать что такое Dll Hell...
Это к вопросу рекомендаций от MS. Они много чего рекомендуют, но порекомендовать дело 2-ух минут, а переписывать приложение занятие совершенно другого времени.

D>>Да SHGetSpecialFolderLocation выдает AllUsers. И туда можно зайти и там что-то написать. Но (сюрприз) это токлько ссылка на ProgramData. То что мы напишем в AllUsers автоматом появляется ProgramData и наоборот. В FAR-е это хорошо видно что это не папка, а ссылка. В проводнике ProgramData вообще скрыта по умолчанию.
D>>Ссылка сделана скорее всего для совмесимости с пред. версиями Винды.

MP>Для приложения это абсолютно не важно. Сегодня — ProgramDara, завтра — ключ в реестре, послезавтра — так всеми любимое облачное хранилище. Для этого (чтобы приложению было фиолетово и оно работало везде) и есть SHGetSpecialFolderPath и прочее. Т. е. по ID Special Folder получаете путь к ней и работаете. Кстати, в Win 7 не только AllUsers ссылка — там их куча. А если задача стоит сделать результат работы (файл) видимым пользователю — пишем Shared Documents (Общие документы). Если что — это тоже ссылка, но она видна в проводнике.
Слушайте, братцы. А вот если портабельная версия, что тогда? Если софтина с флешки работает? И ей попросту необходимо держать какие-либо данные где-то рядом с собой. Тогда как? Как эти все ховенные SHGetSpecialFolder помогут!?!
Понимаю, что в ветке несколько другая ситуация обсуждается и вариант с портабельностью скорее всего просто не в ту степь. Но все же!?! (просто у меня схожая ситуация, и как-то обсуждали где-хранить рабочие материльцы\настройки\и_прочия)

Здравствуйте, Carc, Вы писали:

C>Угу, угу. А еще со времен вин95 были рекомендации класть все ДЛЛ в %SYSTEM%, а мы не читали этих рекомендаций и теперь не приходится въезжать что такое Dll Hell...
C>Это к вопросу рекомендаций от MS. Они много чего рекомендуют, но порекомендовать дело 2-ух минут, а переписывать приложение занятие совершенно другого времени.

Вот и зря. Общие для всех приложений одной конторы DLL должны лежать в Common Files. И если бы так все поступали, то не было бы DLL Hell. А в System клались только системные DLL. Причем — глобальносистемные. А то есть любители перетирать новые версии старьем. Потом из-за таких вот "не читал, но осуждаю" и проблемы. Так что настоятельно рекомендую таки почитать. Не считайте себя умнее разработчиков ОС.

C>Слушайте, братцы. А вот если портабельная версия, что тогда? Если софтина с флешки работает? И ей попросту необходимо держать какие-либо данные где-то рядом с собой. Тогда как? Как эти все ховенные SHGetSpecialFolder помогут!?!
C>Понимаю, что в ветке несколько другая ситуация обсуждается и вариант с портабельностью скорее всего просто не в ту степь. Но все же!?! (просто у меня схожая ситуация, и как-то обсуждали где-хранить рабочие материльцы\настройки\и_прочия)

Ну так на флешке нет ограничений, таких как на ProgramFiles. Там уж сам куда угодно клади. И DLLки свои с собой таскай.

P.S. Кстати, вот, Borland тоже не читал те самые рекомендации. Имеет теперь анонизм с D6-D7, которая проекты в ProgramFiles хранит и компилит (по-умолчанию, а вот пакеты из иного места она в принципе не видит).

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Khimik.

O>Грубо говоря, Вам нужно подключить ко всем исполняемым файлам специальные манифесты.
O>Манифест — это просто текстовый ресурс в формате XML, который, кстати, может лежать
O>рядом с исполняемым файлом. Его содержимое может быть примерно таким:
O>

O><?xml version="1.0" encoding="utf-8" standalone="yes"?>

O><assembly
O>    xmlns="urn:schemas-microsoft-com:asm.v1"
O>    manifestVersion="1.0">

O>    <assemblyIdentity
O>        type="win32"
O>        name="Company.Product.Module"
O>        version="1.0.0.0"
O>        processorArchitecture="x86">
O>    </assemblyIdentity>

O>    <description>My Cool Module</description>

O>    <dependency>
O>        <dependentAssembly>
O>            ...
O>        </dependentAssembly>
O>    </dependency>

O>    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
O>        <security>
O>            <requestedPrivileges>
O>                <requestedExecutionLevel
O>                    level="asInvoker"
O>                    uiAccess="false"/>
O>            </requestedPrivileges>
O>        </security>
O>    </trustInfo>

O>    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
O>        <application>
O>            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
O>            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
O>        </application>
O>    </compatibility>

O>    <application xmlns="urn:schemas-microsoft-com:asm.v3">
O>        <windowsSettings>
O>            <dpiAware
O>                xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
O>        </windowsSettings>
O>    </application>

O></assembly>
O>

O><assemblyIdentity> нужен для идентификации исполняемого файла или динамической библиотеки.
O>Это обычная метаинформация, но иногда она может играть важную роль при выборе
O>нужной версии сборки.

O><description> опционален.

O>В <dependency> прописываются зависимости от различных общих и частных сборок,,
O>установленных на компьютере, от конкретных их версий (это один из механизмов разруливания
O>проблемы "Dll Hell"). Типичный пример — зависимость от библиотеки Common-Controls шестой версии.

O><trustInfo> определяет, какие уровень прав требуется для корректной работы приложения.
O>Варианты: asInvoker — запуск с правами пользователя, highestAvailable — максимально возможный
O>уровень (пользователю будет показано окно с предложением ввести имя пользователя и пароль),
O>requireAdministrator — приложению требуются администраторские права (снова будет запрос UAC).
O>Подсказка: highestAvailable и requireAdministrator большинству нормальных приложений почти
O>никогда не нужны.

O><compatibility> нужен приложениям на Windows 7 и выше, которые хотят "включить" все заплатки,
O>выпущенные после выхода Vista, и работать напрямую, без "эмуляции" поведения Vista.
O>Например, есть известный глюк в GetOverlappedResult, который починили только в Windows 7,
O>однако для совместимости оставили возможность сохранить старое поведение этой функции.

O><dpiAware> показывает, что приложение будет правильно отображаться на настройках с высоким DPI.
O>Без этой опции все GUI-шные элементы на таких настройках будут просто и тупо растянуты.

O>Такой файл манифеста нужно сохранить (в UTF-8) и включить в exe как ресурс.
O>Тип ресурса — 24, ID — 1 (для dll ID равен 2). Либо можно положить данный файл прямо рядышком с
O>exe-файлом, присвоив ему соответствующее имя. Например, для myprogram.exe манифест должен
O>называться myprogram.exe.manifest.

O>После описанных манипуляций загрузчик Windows будет воспринимать данный exe как полностью
O>совместимый с Vista/Windows 7 и никакая виртуализация задействована не будет.
O>Это, разумеется, потребует полного отказа от запись в системные папки и разделы реестра, а
O>также соблюдения всех остальных, документированных в MSDN, "норм поведения".

GetTempPath — это не системная папка? Если всё-таки системная, как совместить запись в неё с использованием этого манифеста?

Я прикрутил этот манифест, не помогло

Здравствуйте, Khimik, Вы писали:

K>GetTempPath — это не системная папка? Если всё-таки системная, как совместить запись в неё с использованием этого манифеста?

K>Я прикрутил этот манифест, не помогло

Не системная.
Эта папка лежит в профиле пользователя, примерно по такому пути — Users\myname\AppData\Local\Temp.
И для доступа к ней на запись не требуются никакие особые права.
Все должно работать, ищите ошибку.

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Khimik, Вы писали:

K>>GetTempPath — это не системная папка? Если всё-таки системная, как совместить запись в неё с использованием этого манифеста?

K>>Я прикрутил этот манифест, не помогло

O>Не системная.
O>Эта папка лежит в профиле пользователя, примерно по такому пути — Users\myname\AppData\Local\Temp.
O>И для доступа к ней на запись не требуются никакие особые права.
O>Все должно работать, ищите ошибку.

GetTempPath может возврощять C:\windows\temp

Здравствуйте, Khimik.

Вот неплохая вводная статья, охватывающая наиболее общие аспекты совместимости при
переносе кода на NT 6.x (Vista и выше) — http://msdn.microsoft.com/ru-ru/library/bb757005.aspx
Для составления контрольного списка проблем очень полезна.

Здравствуйте, swal, Вы писали:

S>GetTempPath может возврощять C:\windows\temp

Кстати, да. И в этом случае в нее сможет писать только администратор или система.

Здравствуйте, swal, Вы писали:

S>GetTempPath может возврощять C:\windows\temp

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

Ваш К.О.

P.S. Раньше встречались юзеры у которых GetTempPath возвращала C:\

	От:	Khimik
	Дата:	19.04.12 12:08
	Оценка:

	От:	Neud
	Дата:	19.04.12 12:13
	Оценка:

От:	vladrsdn	http://vvh-ru.blogspot.com/
Дата:	19.04.12 12:20
Оценка:	-1

	От:	drpops
	Дата:	19.04.12 12:28
	Оценка:	1 (1)

От:	MikePetrichenko	www.btframework.com
Дата:	19.04.12 12:40
Оценка:	+1

От:	drVanо	https://vmpsoft.com
Дата:	19.04.12 12:51
Оценка:

От:	okman	https://searchinform.ru/
Дата:	19.04.12 13:29
Оценка:	+1

От:	wellwell	https://www.softperfect.com
Дата:	20.04.12 00:14
Оценка:

От:	Carc	http://www.amlpages.com/home.php
Дата:	20.04.12 07:48
Оценка: