пятница, 10 декабря 2010 г.

workaround for MSTSC window minimization curse == RemoteDesktop_SuppressWhenMinimized

Года два назад я интересовался проблемой присущей ряду инструментов функционального тестирования приложений в сценариях работы на удаленных машинах доступ к которым предоставляется через стандартный клиент Microsoft Terminal Services Client. Завел я тогда вот этот топик, в надежде добиться правды, но без результата. Проблема была следующая:  когда окно клиента минимизируется - удаленная станция получает уведомление от клиента о том, что его больше не интересуют обновления от сервера (output suppression).

Штука хорошая, экономит трафик - однако сервер при этом помимо обеспечения простой "тишины в эфире" еще и защищает станцию, активизируя winlogon в целях безопасности. Ряд API, связанных с управлением мышью и клавиатурой, благополучно перестают работать и соответственно тестирование  не приведет ни к чему хорошему.

Теоретически решение этой проблемы достаточно простое - например, "научить" клиента не отправлять серверу output supression сообщения, однако официального способа сделать это в mstsc тогда так и не нашлось (хотя помнится для альтернативного клиента rdesktop был даже соответствующий патч).

И хотя я уже потерял интерес к этой проблеме, было приятно увидеть, что недавно ее решение опубликовали.  Полагаю (и это мое личное мнение) Microsoft дал добро на разглашение уже известного некоторым игрокам рынка функционального тестирования решения, которое, как обычно, заключается в добавлении Правильного Параметра в Правильное Место реестра. Для деталей погуглите вот так - RemoteDesktop_SuppressWhenMinimized.

Мне кажется любопытным еще тот факт, что с небольшим интервалом эта информация появилась в источниках от двух конкурирующих продуктов- это TestComplete от Automated QA и Quicktest Professional от HP и насколько можно судить из коментариев - пользователи TestComplete как-то лучше прочувствовали важность этого решения, нежели пользователи близкого мне QTP. Даже разочаровался немного...

Incremental Linking

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

Это благополучно ломает код, сканирующий другие функции с целью подмены нескольких байтиков в заранее заготовленных (например с помощью ассемблера) местах. Причина в том, что взятие адреса для такой функции возвращает (впоне логично) адрес прыжка на функцию, а не на старт функции как можно было бы ожидать. Следовательно, сканирующая функция (если она не подготовлена к такому повороту событий) будет шерстить по памяти с непредсказуемым результатом.

четверг, 28 октября 2010 г.

Mallocate

Баян, конечно, но что поделать :)

channel9.msdn.com/Shows/Going+Deep/Stephan-T-Lavavej-Digging-into-C-Technical-Report-1-TR1

Посмотрел это видео с удовольствием (блин, звучит как-то пошло!).

Во-первых, Стив здоровски владеет предметом и это чувствуется. Практически тянет на SteveCpp, если принять AlenaCpp за эталон. Признаюсь (к стыду своему), что узнал много нового.. или даже вот так правильнее - узнал, что не знаю еще много чего нового :)

Во-вторых, нравится мне когда ребята из Майкрософт ссылаются на хорошие книги и используют забавные словечки. Обратили внимание? Стив использует "mallocate" и "news" так, как будто в американском девелоперском английском уже давно присутствуют глаголы to mallocate и to new. Приглянулись мне эти словечки, даже задумался как бы в русскоязычной среде их внедрить? "Маллоцировать", "маллочить", хм..

вторник, 26 октября 2010 г.

Продуктивный программист

Прочитал на днях книгу "Продуктивный программист" Нила Форда. Поначалу она не слишком привлекла меня - несколько вводных страниц, на мой субъективнеший взгляд, автор посвятил раскручиванию себя любимого (помните как у Жванецкого в Одесском Пароходе "я - капитан, а вы все - дерьмо..."). Потом, правда, я как-то углубился, благо читается она легко, и вынес для себя кое-чего интересного. В целом - книженция достойна рекомендации в категории "развитие здравого смысла у программистов", хотя C++ программисты скорее всего будут ощущать неприятный привкус Java ;)

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

К примеру, дано такое утверждение: "В любом языке с развитым механизмом отражения слово private все равно не более чем документация намерений; чтобы добраться до нужных методов я всегда могу воспользоваться отражением". Ничего себе! Не могу представить чтобы нечто подобное было акутальным для C++ - неужели Java настолько переврала все чему учил Страуструп? или все станет на свои места, если познакомиться с Java поближе?

Из того что понравилось - лаконичное освещение некоторых несложных принципов (DRY, YAGNI, SLAP) - по делу и так, чтобы не заскучать. Странно, но именно в этой книженции я впервые прочитал о "разъяренных обезьянах" - это такой шикарный анекдот с равными долями шутки и правды. Весьма улыбнула меня также тема стрижки яков - теперь я знаю как оставаясь в рамках приличия донести мысль о том, что кто-то занимается ерундой.