У меня на семёрке в Firefox была похожая проблема, только окно становилось полностью белым. Исправилось то ли с новой версией Firefox, то ли с новой версией видеодрайвера.
На десятке самые серьёзные из замеченных проблем:
— Утечка памяти ядром. Через пару дней аптайма приложения начинают сыпаться с Out of memory. Исправляется выключением Superfetch.
— Пропадание ярлыков из «Пуска». Пришлось поставить Wox для запуска программ.
Я оставил загрузчик Windows основным, а Kubuntu подключил через EasyBCD (можно также скопировать загрузочный сектор в файл руками и добавить через bcdedit). Полёт нормальный, в качестве бонуса можно выбрать ОС мышкой.
В rescue mode у меня тоже сваливалось, причина оказалась в смене UUID у раздела, указанного в fstab.
Это вроде как фишка Оперы. Помню, когда у меня ещё был смартфон на Symbian, первыми ссылками всегда прописывались несколько сайтов МТС. Причём если их удалить или заменить на свои, через некоторое время всё возвращалось обратно.
А если пост в нескольких хабах — будет в ридере нескольно раз. Хотя можно через Yahoo Pipes их объединить и отфильтровать дубликаты.
Ещё есть вариант подписаться на geektimes.ru/rss/?with_hubs=true и фильтровать по хабам регулярками в ридере или том же Yahoo Pipes. Тогда и новые хабы мимо не пройдут, если не будут явно отфильтрованы.
В целях демонстрации настраивать HTTPS необязательно. WIF прекрасно работает по HTTP (хотя отдельные Identity Providers, например ADFS, требуют HTTPS). А для подписи токенов можно использовать произвольный сертификат, главное, чтобы у STS был доступ к приватному ключу. Класть его в Trusted Root Certification Authorities не нужно.
Из-за дифракции любой световой пучок расходится, поэтому плотность энергии будет падать. А сфокусировать пучок точно на цель на большом расстоянии тоже нетривиальная задача.
А зачем netcat? Я полные бэкапы вообще одной строчкой делал: adb shell su -c dd if=/dev/block/mmcblk0p12 | dd of=userdata.img
Скорость была около 3 МБ/с в cygwin.
.NET там только гля гуёвых утилит. Память сервер просто так ест, про запас. Я его обычно просто выгружаю в своп при старте системы, там он большей частью и остаётся. Объём памяти как-то должен настраиваться через конфиги, но разбираться было лень.
Отлично, теперь у них устаревшая полная версия бесплатна (вернее, триал на год). Раньше бесплатной была только обрезанная (зато последняя), да и то к концу моего обучения начали за неё денег просить.
У древнего Symbian весь интерфейс был векторный и иконки в SVG, и не тормозило на процессорах с 200 MHz. Тормоза в браузерах, вероятно, дело времени. Почти никто не использует SVG, вот его и не оптимизируют. А можно хотя бы растрированные картинки кэшировать (в Firefox уже что-то сделано), тогда множество одинаковых иконок тормозить браузер не будут. Впрочем, не всё так просто, в WebKit кэширование наоборот пришлось убрать.
Module Initializer компилятором C# не поддерживается, но его можно задать через IL (удобно для этого использовать Fody).
Вот только, как оказалось, Module Initializer автоматически после загрузки DLL не вызывается, он выполняется только когда происходит первое обращение к управляемому коду, чего Mathcad, конечно же, делать не будет.
Вообще я не вижу простого способа зарегистрировать функции, не помещая потенциально опасного кода в нативный DllMain. Разве что на этапе построения сборки с функциями генерировать независимый C++-код для регистрации в DllMain (с захардкоженными FunctionInfo) и линковать его в исходную сборку, как описано здесь. Адреса функций тогда тоже должны быть статическими, для этого прокси тоже надо влинковать в исходную сборку и экспортировать как C-функции.
В общем, прямой вызов управляемого кода из DllMain, как у вас, значительно проще, хоть и небезопасен. Можно написать всё, кроме этого кусочка, на C#, а затем слинковать, как описано по ссылке выше.
Если бы Mathcad вызывал экспортированную функцию для инициализации (большинство программ с поддержкой плагинов делают именно так), можно было бы обойтись чисто управляемым кодом, но увы. Видимо, разработчики не предполагали, что для получения адресов из своей же DLL плагину понадобится плясать с бубном.
Как-то так, для каждой функции адрес, соответственно свой:
// Создаёт прокси для функции и возвращает адрес для вызова.
IntPtr GetFunctionAddress(IFunction function)
{
// Создает прокси, где метод Invoke вызовет IFunction.NumericEvaluation и обработает исключения.
var proxy = ProxyBuilder.GetProxy(function);
var method = proxy.GetType().GetMethod("Invoke");
// Создаёт тип делегата с конкретными типами параметров, приправленными [MarshalAs].
var delegateType = ProxyBuilder.GetDelegateType(method);
// TODO: Делегат надо закешировать, чтобы GC его раньше времени не прибил.
var @delegate = Delegate.CreateDelegate(delegateType, proxy, method);
// Получает адрес неуправляемой прослойки для вызова прокси.
return Marshal.GetFunctionPointerForDelegate(@delegate);
}
Я бы и ваш IFunction превратил в просто метод объекта с конкретными типами параметров, из них можно и метаданные вывести. И атрибуты для уточнения.
Для генерации прокси можно и Linq.Expressions вместо Reflection.Emit использовать, код будет попроще. Делегат создаётся весьма неочевидным образом, к этому надо ещё и генерацию атрибутов добавить.
Впрочем, на практике я данный метод не использовал, был опыт только с фиксированным набором параметров, там всё в разы проще.
На десятке самые серьёзные из замеченных проблем:
— Утечка памяти ядром. Через пару дней аптайма приложения начинают сыпаться с Out of memory. Исправляется выключением Superfetch.
— Пропадание ярлыков из «Пуска». Пришлось поставить Wox для запуска программ.
В rescue mode у меня тоже сваливалось, причина оказалась в смене UUID у раздела, указанного в fstab.
Ещё есть вариант подписаться на geektimes.ru/rss/?with_hubs=true и фильтровать по хабам регулярками в ридере или том же Yahoo Pipes. Тогда и новые хабы мимо не пройдут, если не будут явно отфильтрованы.
adb shell su -c dd if=/dev/block/mmcblk0p12 | dd of=userdata.imgСкорость была около 3 МБ/с в cygwin.
Вот только, как оказалось, Module Initializer автоматически после загрузки DLL не вызывается, он выполняется только когда происходит первое обращение к управляемому коду, чего Mathcad, конечно же, делать не будет.
Вообще я не вижу простого способа зарегистрировать функции, не помещая потенциально опасного кода в нативный DllMain. Разве что на этапе построения сборки с функциями генерировать независимый C++-код для регистрации в DllMain (с захардкоженными FunctionInfo) и линковать его в исходную сборку, как описано здесь. Адреса функций тогда тоже должны быть статическими, для этого прокси тоже надо влинковать в исходную сборку и экспортировать как C-функции.
В общем, прямой вызов управляемого кода из DllMain, как у вас, значительно проще, хоть и небезопасен. Можно написать всё, кроме этого кусочка, на C#, а затем слинковать, как описано по ссылке выше.
Если бы Mathcad вызывал экспортированную функцию для инициализации (большинство программ с поддержкой плагинов делают именно так), можно было бы обойтись чисто управляемым кодом, но увы. Видимо, разработчики не предполагали, что для получения адресов из своей же DLL плагину понадобится плясать с бубном.
Я бы и ваш IFunction превратил в просто метод объекта с конкретными типами параметров, из них можно и метаданные вывести. И атрибуты для уточнения.
Для генерации прокси можно и Linq.Expressions вместо Reflection.Emit использовать, код будет попроще. Делегат создаётся весьма неочевидным образом, к этому надо ещё и генерацию атрибутов добавить.
Впрочем, на практике я данный метод не использовал, был опыт только с фиксированным набором параметров, там всё в разы проще.