При установке некоторых программ (в том числе моей) под 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;

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

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

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

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


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