Win32: Предложения за тестване на проявено приложение срещу внедряване

Започвайки с Windows Vista, Microsoft добави клас подложки за съвместимост, които ще позволят на приложение, което приема, че има административен файл и регистър достъп, да продължи да функция.

С други думи: Приложение, което е неуспешно на Windows XP ще работи на Windows Vista.

Тези осигурени от операционната система корекции на грешки могат да бъдат деактивирани чрез добавяне на раздел към манифеста на приложението, деклариращ, че приложението трябва да работи asInvoker:

<!-- Disable Windows Vista standard user compatability heuristics -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
   <security>
      <requestedPrivileges>
         <requestedExecutionLevel level="asInvoker"/>
      </requestedPrivileges>
   </security>
</trustInfo>

В идеалния случай разработчикът би тествал своето приложение, за да се увери, че то не изисква (ненужно) административни права. За да мога да тествам това, ще трябва да го манифестирам като Invoker.

Но когато се стигне до това, няма да пусна приложението на клиента, проявен asInvoker. Ако съм пропуснал нещо, не искам потребителят да бъде засегнат. Искам операционната система на Microsoft да поправи грешките ми. Проблемът с това решение е:

  • трябва да модифицирам manfiest преди пускане
  • никога няма да разбера за нещата, които съм пропуснал, защото те просто работят на Windows Vista.

Подобна главоблъсканица възниква с поддържаната ОС< на Windows 7 /strong> манифест цели. Можете да добавите манифест към приложението, указващ за коя версия на Windows сте проектирани и тествани:

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
   <application> 
      <!--The ID below indicates application support for Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
      <!--The ID below indicates application support for Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
   </application> 
</compatibility>

В случай на елементите поддържана ОС операционната система знае предварително за коя операционна система сте проектирани. Това ще постави вашето приложение в контекста на Windows Vista, ако не кажете, че поддържате Windows 7:

алтернативен текст
(източник: msdn.com)

Това действие е подобно на стартиране на приложение в някакъв режим на съвместимост, напр.:

  • Windows Server 2008 (сервизен пакет 1)
  • Windows Vista (Service Pack 2)
  • Windows Vista (сервизен пакет 1)
  • Windows Vista
  • Windows Server 2003 (сервизен пакет 1)
  • Windows XP (сервизен пакет 2)
  • Windows 2000
  • Windows NT 4.0 (Service Pack 5)
  • Windows 98 / Windows Me
  • Windows 95

където ще получите schmorgasboard от приложени подложки за съвместимост и Windows ще емулира старо недокументирано поведение, за да помогне на приложението ви да се срине, когато зависи от това недокументирано поведение.

пример за подложки за съвместимост, които Windows 7 ще предостави за приложение, работещо в контекста на Windows Vista:

  • RPC ще използва стария частен пул от нишки, а не пул от нишки на OS
  • ще можете да заключите основния буфер за дисплей на работния плот за видео
  • ще можете да бледите към основния видео буфер на работния плот, без да посочвате прозорец за изрязване
  • ще бъдете уязвими към състояние на състезание GetOverlappedResult (ако сте зависили от него)
  • ще продължите да получавате смекчаване на асистента за съвместимост на програмата (PCA).

И още веднъж, за да тествам приложението си правилно под Windows 7, трябва да добавя записа в манифеста supportsOS. Но, отново, няма да изпратя приложението с този флаг, защото не искам да загубя предимствата на тези подложки (напр. PCA). И отново, ако дадено приложение има проблеми, които са коригирани, защото е работило в контекста на Vista: никога няма да науча за това от нашите клиенти - защото приложението просто работи.


мисли? Насоки? Най-добри практики?


person Ian Boyd    schedule 10.11.2009    source източник
comment
Това е много добър въпрос.   -  person i_am_jorf    schedule 10.11.2009
comment
Ако оставите манифеста (asinvoker), тогава НЯМА да бъдете уведомени за проблем. Windows просто ще извика своята UAC евристика и безшумно ще използва виртуални папки и кошери на виртуалния регистър, за да изпълни грешните заявки на вашето приложение. AsInvoker всъщност ще доведе до получаване на грешка в приложението ви, ако се опитате да надхвърлите рейтинга си за сигурност - и следователно можете действително да го намерите и отстраните грешки. Имате концепцията наобратно, AFAICT   -  person Mordachai    schedule 02.12.2009
comment
Мордачай: Да, това (мислех) гласи въпросът ми. Ако нямам манифест, Windows ще коригира проблемите. Ако добавя манифеста, евристиката е деактивирана.   -  person Ian Boyd    schedule 03.12.2009
comment
За да мога да тествам това, ще трябва да го манифестирам като Invoker. проявявам го, докато тествам, така че виждам грешки (защото евристиките са деактивирани). няма да пусна приложението на клиента, проявен като Invoker. Ако съм пропуснал нещо, не искам потребителят да бъде засегнат. И отнемам записа в манифеста за освобождаване.   -  person Ian Boyd    schedule 03.12.2009


Отговори (3)


няма да пусна приложението на клиента, проявен като Invoker. Ако съм пропуснал нещо, не искам потребителят да бъде засегнат.

Мисля, че това е лош подход. Моят съвет е да манифестирате правилно от самото начало и да тествате това, което внедрявате.

Microsoft няма да се прегърби за съвместимостта на всички. Те ще се насочат към най-честите грешки с голямо въздействие, направени от най-големите доставчици. Ако пропуснете някакъв малък проблем, шансът те да предоставят подложка в бъдеще е малък.

Всеки път, когато Microsoft добави подложка за съвместимост, всички плащаме цена. Има API, които не работят по начина, по който би трябвало, защото трябваше да се справят с някакъв случай по мозъчно мъртъв начин, за да постигнат съвместимост с грешката на някой друг. Това означава дълги, болезнени сесии за отстраняване на грешки, означава преминаване през по-дълга (или по-малко пълна) документация и означава малка неефективност в операционната система за всички. Това също означава, че разработчиците на Windows губят време в поправяне на грешки на други хора, вместо да подобряват операционната система.

Понякога тези промени в съвместимостта са големи чукове, които наказват разработчиците, които го правят правилно. Много приложения не обработват високо DPI правилно, така че - в името на съвместимостта - Vista приема, че нито едно приложение не го обработва правилно (освен ако изрично не твърдят друго). Vista прилага мащабиране на потребителския интерфейс. Приложенията, които не са работили с висок DPI, получават подобрени (но неоптимални) резултати. Приложенията, които работеха с high_DPI, получават влошени резултати. (И клиентите, които са използвали добрите приложения, виждат, че те се влошават, когато надстроят до Vista и обвиняват Microsoft.) Разработчиците, които не са платили данъците си, получават помощ от Microsoft, останалите от нас (включително Microsoft) биват наказани. Единственият начин да се избегне това е всеки да си плаща данъците.

Като цяло Microsoft става все по-добър в правенето на тези подложки за съвместимост по-целенасочени (въпреки че Vista беше доста груба). Въпреки това има малко разходи за всеки един.

Следвайте най-добрите практики по време на разработката. Тествайте какво планирате да внедрите. Ако се повреди, Microsoft може да го поправи вместо вас. В противен случай може да се наложи да пуснете актуализация. Това е по-добре, отколкото всички да понесат наказание, защото някои разработчици не са направили правилното нещо.

person Adrian McCarthy    schedule 12.11.2009
comment
съгласен съм с всичко, което каза. Но ако софтуерът се срине поради функция, която специално съм избрал - тогава съм го счупил. Не мисля, че Windows трябва да има подложки, мисля, че приложенията трябва да се повреждат и компанията трябва да ги поправи безплатно за всички свои потребители. Ако една компания не иска да го актуализира, компанията е загубила изходния код или компанията не съществува, тогава някой все още трябва да го поправи. - person Ian Boyd; 12.11.2009

AsInvoker е правилният начин за разпространение на вашето приложение!!!

Всичко, което казва, се изпълнява с идентификационните данни на потребителя. Не се казва „направете нещо подло“ или „използвайте права на администратор“.

Без този манифест вие брандирате приложението си като „Не съм запознат с UAC, така че, моля, предоставете ми каквито и да е хакове, от които се нуждаете, за да ме накарате да функционирам във всяка система, която има UAC“

Но ако приложението ви не се опитва да прави неща само за администратор - и можете лесно да тествате това, като просто влезете като стандартен потребител и след това стартирате приложението си и следите за грешки - тогава AsInvoker е абсолютно правилен.

Това може да ви помогне да се справите с това: Изследване на потребителя на Vista от програмист Контрол на акаунт

person Mordachai    schedule 01.12.2009
comment
Моето приложение не прави (умишлено) нищо, което е само за администратор. Това важи и за почти всички приложения. Ето защо много приложения се провалят, когато работят като истински стандартен потребител. Ето защо Microsoft създаде стандартната потребителска евристика на Vista. - person Ian Boyd; 03.12.2009
comment
и можете лесно да тествате това, като просто сте влезли като стандартен потребител и след това стартирате приложението си и следите за грешки Това не е вярно; не е толкова лесно. Има някои понякога трудни за достигане пътеки на код, които моето собствено тестване може никога да не види. Ако беше лесно, тогава всички програми щяха да са без грешки, защото всеки възможен сценарий вече беше тестван. - person Ian Boyd; 03.12.2009
comment
И накрая, обърнете специално внимание на реда в първоначалния ми въпрос, Ако съм пропуснал нещо.... Ако съм пропуснал нещо, искам приложението да продължи да работи. В крайна сметка работи в XP - но изведнъж се проваля във Vista. Глупава Vista, казва клиентът. И внезапно клиентът отказва да надстрои до Vista, защото тя счупи нашето важно бизнес приложение. - person Ian Boyd; 03.12.2009
comment
Чувам какво казвате: в идеалния случай бихте искали MS да използва каквито и да е подложки за съвместимост, които може да измисли, за да гарантира, че приложението ви ще продължи да работи безпроблемно на каквато и нова версия на операционната система да направи (или сервизен пакет) ). Евристиката на UAC обаче кара много програми да се провалят по трудни за разбиране и правилни начини. Трябваше да поддържам много потребители на наследени приложения, които работят неправилно точно поради подложките за съвместимост на MS и поради начина, по който работят виртуализираният регистър и файловата система. Маркирането на вашето приложение като пред-Vista не ви изолира от проблеми - person Mordachai; 03.12.2009
comment
Просто променя проблемите, на които сте изложени. Прост пример: програма съхранява настройки в HKLM\Software\company\... Това работеше под XP и т.н. Потребителски надстройки до Vista. Софтуерът продължава да работи и показва текущите му настройки ... ДОКАТО потребителят не промени настройка. В този момент софтуерът се опитва да пише в HKLM\Software\company\... и UAC виртуализацията се намесва - създава нов виртуализиран ключ за приложението, в което пише, и сега ТОВА Е ЕДИНСТВЕНИЯТ КЛЮЧ, който приложението може да види на този адрес (всички други свързани настройки са изчезнали, тъй като вече са скрити зад виртуалния ключ. - person Mordachai; 03.12.2009
comment
Същият проблем се случва за папки във файловата система. И има още по-фини проблеми, които възникват поради подложките на MS. В крайна сметка: техните подложки са по-лоши от полезни. В повечето случаи вашето приложение се очаква да направи това, което поиска. Ако нещо ужасно умно е направено отдолу - всеки може да гадае дали е наистина достатъчно умно, за да работи правилно. Според моя опит досега: почти никога. ср. удар на MS гадно силно. - person Mordachai; 03.12.2009

Доколкото разбирам, вместо да предоставя манифестен файл с вашата дистрибуция, той може също да бъде свързан директно към вашия EXE файл чрез добавяне на следната команда към ресурсния файл на вашето приложение: [1,2].

CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "YourApp.exe.manifest"

Отделен манифестен файл в директорията, съдържаща EXE файла, може да замени този свързан манифест, но това зависи от клиента. Ти не би го предоставил.

Сега компилаторът на ресурси "RC" от Microsoft приема директиви за препроцесор като #ifdef [3]. Което означава, че бихте могли да инструктирате вашето Visual Studio да има две отделни цели за изграждане, дефиниращи различни дефиниции на препроцесора, като ТЕСТВАНЕ и РАЗГЛАШАВАНЕ.

След това е просто въпрос на използване на директиви #ifdef, за да използвате два различни манифестни файла за вашите цели за тестване и изграждане на внедряване и можете да редактирате манифестните файлове, както желаете. Това ще реши ли проблема ви?

[1] http://msdn.microsoft.com/en-us/library/ms997646.aspx
[2] http://doc.ddart.net/xmlsdk/htm/sdk_dependencies_5wvi.htm
[3] http://msdn.microsoft.com/en-us/library/aa381033%28VS.85%29.aspx

person littlegreen    schedule 11.11.2009
comment
Мислех за външния манифест. Но започвайки с Windows Server 2003 и по-нови, всеки вътрешен манифест е за предпочитане пред .manifest файл (blogs.msdn.com/junfeng/archive/2009/05/11/) - person Ian Boyd; 11.11.2009
comment
Е, това дори е добра новина, защото решението, което описвам по-горе, е внедрено с вътрешния манифест, не с външния. Страхувам се, че не бях достатъчно ясен.. трябва ли да го обясня по-добре? - person littlegreen; 12.11.2009
comment
Отделен манифестен файл в директорията, съдържаща EXE файла, не може да замени свързания манифест. би трябвало да мога да добавя дефиниране, за да не включва манифеста, правейки софтуера да използва външен manfiest. - person Ian Boyd; 12.11.2009
comment
Наистина, вие сте прав: друг начин е да използвате #ifdef за избор между вътрешния и НЕ манифеста, така че външния манифест, вместо между два вътрешни манифеста. Ефектът би бил същият. - person littlegreen; 13.11.2009