По–хорошему, window messages надо тоже асинхронно обрабатывать, в том числе отправку. Я имею в виду WM_SETLISTITEM и прочие. Повторяю, отправку, а не только получение. У GUI тоже есть давление, особенно это чувствуется по RDP. RDP, в отличие от других удалённых рабочих столов, не может сам по себе потерять кадр. Если приложение что–то делает, эти действия прокачиваются через RDP, и если действий много, то все действия прокачиваются с той скоростью, с которой позволяет связь. Какие–то приложения, похоже, умные, и не пытаются во что бы то ни стало прокачать все кадры, а какие–то нет. Хорошо бы, чтоб мои были умнее.

https://code.google.com/p/angleproject/ — реализация OpenGL API через DirectX

http://edll.sourceforge.net/ Вот такая шняга есть под Windows. Умеет подгружать в рантайме статические и динамические библиотеки. Особенно интересно последнее. Если системному LoadLibrary() нужен непременно файл на файловой системе, то кастомный загрузчик, наверное, и из виртуального файла загрузить DLL устроило бы. Например, из инкрустированного в .exe байтового потока. Или из удалённого HTTP сервера, попутно перехватив FileOpen у подгруженной библиотеки, чтоб она и файлы читала оттуда же.

https://forums.embarcadero.com/message.j.....319#484319 Почему нельзя делать WinRT приложения для MS app store кроме как на говноязыках: > You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management... Any calls to those APIs from your application will automatically disqualify your application from being an "official" WinRT application capable of delivering through the MS app store. > > Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user's app.

http://www.thomgerdes.com/2011/12/winrt-.....files.html Один из немногочисленных пока обзоров Windows Runtime. > The first thing I noticed is that Windows is doing a lot to break the API down into Namespaces, and for the most part each metadata file describes one namespace. So my first reaction was to put the contents of each metadata file into one Delphi unit. This doesn't quite work though because of a few things: One metadata file may actually contain multiple namespaces, one namespace might be included in several metadata files, and there are circular dependancies between types in the various metadata files. Не ожидал такого дерьма от Microsoft. Это же из C++, это должно быть похоронено, алё? Один файл – один модуль, имена одинаковые. Что опять за творчество восьмидесятых? > Generic Interfaces > Generics are used pretty heavily throughout WinRT. In the C++ language bindings, they end up translating down to a template class, and the pre-compiled headers actually have to parametrize every instance of a generic class. This is pretty ugly and it'd be much nicer to just declare the interface and have the compiler do the right thing. Delphi has a similar problem for similar reasons. Generic Interfaces are supported by the compiler, but the problem arises in that you cannot specify a GUID for parametrized instances of a given generic interface. So for now, I've had to create a unique interface for every parameterized interface in WinRT. А вот про Generics в API не знал. Здесь WinRT лучше, чем IBM SOM. Однако, > But how do you go about assigning a GUID to the interfaces? The answer lies in RoGetParameterizedTypeInstanceIID. Функция эта доступна только в Windows 8, из–за этого нельзя компилировать с других OS. Кстати, не проверял, но, может быть, было бы достаточно унаследовать GUID–интерфейс от не–GUID–ного generic interface. Ну или оставить generic interface as is, а получать его через Supported(), а GUID вычислять на целевой платформе. Впрочем, компилятор следующей версии Delphi наверняка изменится в такую сторону, что эти workaround станут не нужны. Что нравилось в Delphi, так это сращивание с компонентными технологиями Windows до такой степени, что использовать их из Delphi удобнее, чем из C++ и C# от Microsoft. Это же и её минус как плохо переносимого ЯП. Я раньше думал, это Borland додумался TDateTime сделать из Double. Ан нет, это из COM пошло. Ну хоть проблема 2000 не грозит на время существования Солнечной Системы. Плохо, что WinRT доступен только в Win8. Потребуется лет восемь, чтобы на нём можно было писать для массового пользователя. Лучше бы, наоборот, в 2001м году вместо .NET был бы выпущен WinRT, входил бы в обновления OS и был бы доступен везде, а .NET, наоборот, был бы доступен не ранее какой–нибудь версии Windows.

http://www.cs.wustl.edu/~schmidt/win32-cv-1.html > Both Win32 events and POSIX condition variables provide similar waiting, signaling, and broadcasting features. For instance, WaitForMultipleObjects can acquire a mutex and wait on an event simultaneously via the waitAll flag and SignalObjectAndWait can release a mutex and wait on an event atomically. These functions provide semantics akin to the pthread_cond_wait and pthread_cond_signal. Thus, there are instances where either events and condition variables can be used interchangably. > However, extreme care must be taken with Win32 events to ensure that there are no race conditions introduced when switching from one mechanism to another. Unfortunately, there's no way to release just one waiting thread with a manual-reset event. Likewise, there's no way to release all waiting threads with an auto-reset event. This limitation is a major source of difficulty when implementing condition variables, as shown in Section 3. > After years of repeatedly seeing Win32 implementations of condition variables posted in newsgroups like comp.programming.threads it became apparent that many Win32 implementations are either incorrect or contain subtle problems that can lead to starvation, unfairness, or race conditions. To help developers avoid these problems, this article evaluates common strategies for implementing POSIX condition variables on Win32, illustrating common traps and pitfalls and ways to avoid them.

DCCOSX.EXE собрал Hello World как по маслу, но на Mac OS X 10.4 он не запустился. Какая–то команда динамического загрузчика не поддерживается. Надо бы настоящий мак купить с новой OS, а то ничего нового уже не работает. Вообще, обидно, что то, что компилируется и запускается под Windows 2003ей, не работает на Mac OS X 2005го года.

Remote Desktops из adminpak в чём–то получше обычного RDC будет

Зря я раньше не использовал win-bash ( http://win-bash.sourceforge.net/ ). Он, оказывается, рабочий, несмотря на разницу в операционных системах. Кроме bash, я использую UnxUtils и GnuWin32: http://unxutils.sourceforge.net/ http://gnuwin32.sourceforge.net/ В GnuWin32 which корректнее работает, а в UnxUtils лучше дела с кириллицей в sed. В общем, по обстоятельствам.