Не вижу особого смысла в этом. Ибо апи-функций - тьма, пока все опишешь - появится ОС следующего поколения. А там и новое железо. Считаю, что делать нужные обертки надо в соответствующих приложениях по мере необходимости. В развитие современных и самых популярных ОС вкладываются огромные ресурсы, а сложность ОС огромна. Чтобы инструмент разработки ПО был успешным, он должен соответствовать ОС, а для этого ему надо развиваться одновременно с ОС.

Про это я писал в конце "довеска". Но, во-первых, какой-то win-интерфейс все равно нужен, а, во-вторых, чем в данном случае MD отличается от любой другой железяки, для которой требуется написать красивый драйвер?

Вообще, конечно, можно свести взаимодействие программы и API к более простой схеме, но это (отдельная от программирования) достаточно нетривиальная задача

Для эьтого нужно описать "человеческое лицо" в терминах самой общей логики - человеческой что ли, а ни в коем случае не в терминах всё тех же вызовов API
может случиться, что какое-то сведение (редукция ) второго к первому возможна

Т.е. интерфейс с устройством в отсутствие самого устройства? Тогда я рекомендую большую красную кнопку, нажатие на которую производит нужное нам в данный момент действие.

Возможно, я что-то не так понял...

Да я сам виноват, постоянно сбиваюсь с разговора об интерфейсе API-программист на API-пользователь. Если во втором случае, действительно, можно размышлять о машинно-независимом идеале, то в первом, чего бы мы от Windows не хотели, API нам не обойти.

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

Речь о том. что если нам нужно удобство программиста, то нужно начинать с удобства программиста
Если мы говорим, что интерфейс API перегружен или избыточен, то мы должны показать, что можно было бы обойтись меньшим, но ГДЕ обойтись - (а где? ) - в логике работы программиста - иначе придётся признать, что интерфейс не перегружен, и это всё каприз. Т.е. для создания программы, программист мог бы использовать меньший или более логичный (что почти одно) набор средств. нежели предлагает (требует) API

берём конкретный пример программирования API и показыаем, что это избыточно сложно, что многие детали программисту не нужны или могли бы быть другими

Именно, и не только "по описанию и поддержке интерфейса". Хотя, в данном случае, вопрос "хочу" совсем не ставится - есть конкретное "железо", требуется конкретный софт. "Хочу" будет только после этого.
Нет, задача состоит в построении интерфейса с API, а не доказательстве его ублюдочности.
Избыточно сложно что? API или способ его использования? Первое нам дано в ощущениях, а второе - целиком зависит от нас.

Если есть конкретная задача, надо и работать конкретно. Смешивать исследования и разработку себе дороже. Конкретный проект делается на том, что есть, при необходимости делаются пометки на будущее. Но тогда уж исследовательский период делается как положено и для себя, с учетом того, что потом на всем этом писать.

Мне показалось , что человческий интерфейс - это именно проще

Если не сокращать и не упрощать - зачем тогда создание интерфейса? повторить? усложнить? Я прошу прощения за непонятливость.

Уже писал, что конкретная задача выглядит так:Здесь только надо учесть, что в (2) непонятно, о каком интерфейсе идет речь. Моя вина. надо бы переформулировать:
2a) Интерфейс программист-API должен позволять программисту быстро и удобно пользоваться известным Win-API.
2б) Этот же интерфейс должен быстро и удобно расширятся при узнавании программистом новых ф-ий Win-API.
2в) Одна из целей этого - быстрое (для программиста) и удобное (для пользователя) создание пользовательских интерфейсов.

А какие парадигмы внутренне свойственны самому WIN-API?
1. Трехфиговое проклятие. Очевидно, MD сам попытался справиться с этой проблемой, введя ресурсы. Т.е. борьба с этой проблемой присуща ему изначально.
2. Объектная ориентированность. Явно выражены и объекты (т.е. окна), и классы. Что-то даже наследуется, то обработчики сообщений, то сама оконная функция...
3. Гомеостатичность. Любое действие пользователя/программы выводит Windows из равновесия, и он пытается его восстановить. К сожалению, часть работы по восстановлению возлагается на самого возмутителя спокойствия.
4. Отказ от многозадачности. Постепенный перенос центра тяжести API с взаимодействия процессов, на многооконные, многофреймовые и многопоточные приложения. С другой стороны, пространства задач разделены в памяти чисто символически.
5. Отсутствие единого стандарта представления информации. Сколько всего было перепробовано, как в части хранения внутренней информации (ini-файлы, реестр, системные каталоги...) так и пользовательской (OLE, Active-X, XML...).
6. Basic-ориентированность. VB де-факто стал естественным средством программирования, офисного и IDE макросостроения и даже WEB-дизайна.
7. Скрытые возможности. Есть огромное количество удачно построенных внутренних механизмов MD, благодаря которым он, все-таки, работает, но они спрятаны очень глубоко.
8. MD - не операционная система. По старой классификации он является вирусом, производя без уведомления пользователя ненужные тому действия на его компьютере.
К сожалению, практически со всем нужно бороться.

Что с этим не так сейчас?
в СПФ для вызова апи надо
WINAPI: PaintDesktop USER32.DLL
и дальше пользуемся именем,
в форке еще проще
ALSO IMPORT USER32.DLL
и пользуемся именем в любом нужном месте.
что сложного именно с использованием-то?

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

Возможно это будет проще, чем воспользоваться win-api, так как в основе будут более ортогональные и менее многочисленные вещи.

Дело в том, что знание имени ф-ии, ничего программисту не дает. Это вам не консоль, где как правильно писал коллега Хищник, никаких проблем с заменой "переменной на массив" не было. Вставляй заглушки, контрольки и заплатки, сколько душе угодно. Здесь нужно досконально знать все четыре контекста, перечисленные в конце прошлой страницы: ВЫЗОВА, КОНСТАНТ, ИСПОЛЬЗОВАНИЯ, ПЕРЕМЕННЫХ. Кроме того, нужно постоянно помнить, что роль всех четырех контекстов постоянно колеблется между свистками/звонками и поддержкой целостности внутренней логики MD. И еще, не надо забывать, что речь идет не только о GUI, но и других частях WIN-API.