LINUX.ORG.RU

wine умеет немного больше или Win32 кросплатформенный api

 , , , ,


0

2

Сегодня случайно открыл для себя что wine это не только запускалка .exe файлов на linux, но также и портированное win32 api.

Наверное, это и так все знают, хотя часто вижу сообщения в духе: «никогда не портируют на linux, так как прибито гвоздями к Win32».

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

Нашёл в интернете hello world на Win32 api:

#include <windows.h>

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
    MSG  msg;    
    WNDCLASSW wc = {0};
    wc.lpszClassName = L"Static Control";
    wc.hInstance     = hInstance;
    wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
    wc.lpfnWndProc   = WndProc;
    wc.hCursor       = LoadCursor(0, IDC_ARROW);

  
    RegisterClassW(&wc);
    CreateWindowW(wc.lpszClassName, L"Native App",
                  WS_OVERLAPPEDWINDOW | WS_VISIBLE,
                  100, 100, 330, 270, 0, 0, hInstance, 0);

    while (GetMessage(&msg, NULL, 0, 0)) {
  
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return (int) msg.wParam;
}

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, 
    WPARAM wParam, LPARAM lParam) {

    static wchar_t *lyrics =  L"Hello World!";

    switch(msg) {

        case WM_CREATE:
      
            CreateWindowW(L"Static", lyrics, 
                WS_CHILD | WS_VISIBLE | SS_LEFT,
                20, 20, 300, 230, 
                hwnd, (HMENU) 1, NULL, NULL);
            break;

        case WM_DESTROY:

            PostQuitMessage(0);
            break;
    }

    return DefWindowProcW(hwnd, msg, wParam, lParam);
}

собрал

winegcc main.c -o hello

создалось два файла:

  • hello.exe
  • hello.exe.so

hello.exe это на самом деле баш скрипт:

#!/bin/sh

appname="hello.exe.so"
# determine the application directory
appdir=''
case "$0" in
  */*)
    # $0 contains a path, use it
    appdir=`dirname "$0"`
    ;;
  *)
    # no directory in $0, search in PATH
    saved_ifs=$IFS
    IFS=:
    for d in $PATH
    do
      IFS=$saved_ifs
      if [ -x "$d/$appname" ]; then appdir="$d"; break; fi
    done
    ;;
esac

# figure out the full app path
if [ -n "$appdir" ]; then
    apppath="$appdir/$appname"
    WINEDLLPATH="$appdir:$WINEDLLPATH"
    export WINEDLLPATH
else
    apppath="$appname"
fi

# determine the WINELOADER
if [ ! -x "$WINELOADER" ]; then WINELOADER="wine"; fi

# and try to start the app
exec "$WINELOADER" "$apppath" "$@"

выглядит как-то так: https://i.imgur.com/u6pzVeJ.png

★★★★★
Ответ на: комментарий от Deleted

Qt хоть тему и диалоги родные умеет.

Угу, умеет. А своих тем у него нет, только мимикрировать под что-либо умеет. В том числе под GTK+, бгг. Причём кривовато.

anonymous
()
Ответ на: комментарий от a1batross

Да, капитанский тред.

Кстати, про очевидность, все конечно знают, но в wine-staging есть gtk3-theming (в winecfg галку установить нужно)

Тогда окошки Win32 выглядят немного покрасивее, чем в обычном wine:

https://imgur.com/rWsjxCo

LINUX-ORG-RU у тебя на скриншоте вроде был обычный wine?

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

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

EXL ★★★★★
()
Ответ на: комментарий от fsb4000

gtk3-theming

Когда я его в последний раз тыкал, он недоделанный был — Total Commander падал из-за того, что виджет дерева этой штукой не покрыт ещё.

anonymous
()
Ответ на: комментарий от EXL

Проблема в том, что венгерка — конвенция и костыль; вот засунуть бы её на уровне синтаксиса языка — другое дело.

anonymous
()
Ответ на: комментарий от EXL

Почем неожиданно-то? На винду вообще можно сделать программу, которая хоть как-то (в том числе через интерпретатор для себя) не дёргает WinAPI?

anonymous
()
Ответ на: комментарий от fsb4000

Я думаю это особенно для всяких arm платок должно помочь

Именно так. Например, таким образом был портирован StartCraft на ARM, вот интересная статья с практическим примером использования Winelib:

https://habr.com/ru/post/215375/

EXL ★★★★★
()
Ответ на: комментарий от hobbit

+1

Одной из причн того, что Windows сегодня является лидирующей десктопной операционной системой является незыблемость WinAPI.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Интересно, есть ли подобные языки, где тип переменной задаётся её именем по типу:

ui32Count = 4;

И насколько такой синтаксис будет удобным. Что-то мне кажется, что удобным оно точно не будет.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Неожиданно не в том, что WinAPI дёргается, а в том, что параметры всяких цветов, шрифтов, кнопочек и прочего берутся именно из него для того, чтобы тулкит мог в системную тему винды.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Открытый и богатый возможностями по расширению и копанию в чужих окошках Win32 идейно не совместим с огороженностью Wayland, поэтому портировать его не будут

Так никто не разрешит WinAPI лезть в чужое окно, перехватывать курсор и ввод из клавы, как он обычно это делает в самой винде. Даже в семерке он мог это делать далеко не везде, а только в рамках одного workstation, который создается отдельный для каждого сеанса и для разных групп системных сервисов.

иначе выйдет обгрызенная кака с отвалившимся треем, скриншотами, скринкастами, заданием размеров окна со стороны приложения

Доступ к экрану нужно задавать. Трей, вроде, не является проблемой, потому что работает через IPC - базовые функции, по крайней мере, то есть, тупо сообщения о клике мышкой. По заданию размера и выпадающим меню я не в курсе политики Wayland, потому что в глаза его не видел еще.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

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

Хром использует GTK на никса, но на форточках у него своя либа, потому что GTK на винде неюзабельно:
http://dev.chromium.org/developers/design-documents/chromeviews
http://dev.chromium.org/developers/design-documents/views-windowing

byko3y ★★★★
()
Ответ на: комментарий от fsb4000

да, и MacOS API тоже порт есть для Windows и Linux, http://www.gnustep.org/
Так что кросплатформа уже почти везде, как бы не старались вендорлочить :)

Поэтому я засунул мак с макпортами в позиксы, но iOS оставил отдельно, потому что оно не работает ни в никсах, ни в винде... по крайней мере пока что. Эпл будет держать свою мобильную платформу до последнего.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

но на форточках у него своя либа

Не своя:

chrome использует:

Mac:Cocoa

Linux: Gtk

Windows: WTL

https://www.hanselman.com/blog/TheWeeklySourceCode33MicrosoftOpenSourceInside...

https://github.com/chromium/chromium/tree/b5f40550a10df6ab799c52429ae70b8c738...

Именно из-за этой WTL chrome и не собирается mingw-w64, так как хотя wtl открыта, но она базируется на atl, которая закрыта :(

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Это не совсем MacOS API, даже близко не MacOS API. Это скорее была попытка воссоздать NeXTSTEP-окружение по заветам GNU, но попытка неудачная, ибо никому не пригодилось.

Возможность запуска приложений с macOS в Linux реализуется в проекте Darling, но в GUI оно так и не смогло.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

GTK не могёт, другие тулкиты могут. Я там ведь не только GTK перечислил. И GTK тоже лазиет в WinAPI не только для создания контекста.

EXL ★★★★★
()
Ответ на: комментарий от byko3y

Даже в семерке он мог это делать далеко не везде

Ну дык закручивание гаек — одна из причин, почему я свалил с винды, ибо винда уже не винда. В восьмёрке, поговаривают, ещё и проверку цифровых подписей для системных файлов ввели, патчить их стало намного сложнее.

Доступ к экрану нужно задавать

Ага, при вызове API замораживать приложение, пока пользователь не ответит. Вон в самой винде так UAC сделали — к уже существущим вызовам, которые раньше свободно работали, нашлепали запросы; вышла такая фигня, что power user'ы её первым делом отключают, ибо надоеда несусветная.

базовые функции, по крайней мере, то есть, тупо сообщения о клике мышкой

Тупо клик — это индикаторы, а не трей; полноценные иконки в трее дофига чего обрабатывать могут, и именно посему, кстати, под сами винду его сторонние реализации кривые.

я не в курсе политики Wayland

Ну видишь ли, есть изначальная политика разработчиков Wayland (всё огородить), а есть политика реальных имплементаторов, вон Drew DeVault и кедерасты вместе чего-то мутят и пытаются исправить ситуацию расширениями протокола. И казалось бы, ну сформируют общий годный стандарт, чистые иксы вон без EWMH, xkb и всяких freedesktop-нашлёпок тоже так себе, то есть проблемы как бы и нет, но! — остальные эти расширения соблюдать не будут, то есть ни в gnome-shell (где тоже выкидывают и огораживают всё подряд), ни в Weston, ни в наколеночных всяких композиторах их никогда не будет. А с ними придётся считаться, с гномом уж точно. И получится, что приложения под линукс тупо будут урезаны по функциональности, либо гномосеки напилят своих велосипедов, которые будут работать напрямую со щелью, а не через расширения Wayland. И разработчики приложений, проприетарных особенно, будут в первую очередь на эти велосипеды таргетироваться, либо тупо дропать функциональность, потому что её нельзя завести без бубна у всех.

anonymous
()
Ответ на: комментарий от EXL

Ну когда юзер явно видит, что тулкиты юзают системную тему, а не мимикрируют или даже не пытаются мимикрировать — это уже не «неожиданно», опять-таки.

Кстати, не подскажешь, есть какие-то готовые либы для чтения msstyles? (кроме Wine-овской реализации, разумеется). Я тут пилю потихоньку демон, который позволит Web-приложениям нативную тему юзать; в приоритете поддержка GTK+3-тем, ибо там тоже CSS и прототип проще реализовать будет, но в перспективе надо и другие платформы покрыть.

anonymous
()
Ответ на: комментарий от EXL

А культи разве тему парсят, а не тупо рисуют виндовые виджеты через WinAPI? С ними же всякие костыли типа VAnim работают, значит, там настоящие виджеты, а не подделки.

anonymous
()
Ответ на: комментарий от anonymous

А культи разве тему парсят, а не тупо рисуют виндовые виджеты через WinAPI?

Я не особо разбирался в этом вопросе, скорее всего они и тему парсят и в WinAPI лазят для рисования видежетов. Там просто есть несколько Windows-тем и некоторые из них кросс-платформенные, как тема windows, которую можно выбрать и в Linux/macOS, а некоторые – платформо-зависимые, как вот эта вот windowsvista для соблюдения msstyles в Vista, 7, 8, 10 и др.

Если узнаешь ответ – является ли сущность QButton из Qt в Windows чем-то подобным – https://docs.microsoft.com/en-us/windows/win32/controls/create-a-button, как ты предполагаешь, дай об этом знать, самому интересно.

EXL ★★★★★
()
Ответ на: комментарий от fsb4000

Именно из-за этой WTL chrome и не собирается mingw-w64, так как хотя wtl открыта, но она базируется на atl, которая закрыта

WTL используется в инстиляторе, обновляторе, каких-то ветках chrome\browser\browser_switcher, chrome\chrome_cleaner, chrome\credential_provider, content\browser\accessibility, ui\accessibility\platform, remoting\host\win, ui\base\ime\win, но ui\views почти никак не зависит от WTL, единственное исключение - ui\views\accessibility\view_ax_platform_node_delegate_win.cc.

То есть, куча нативных фич подрубается из второстепенных модулей и утилит, но само ядро браузера сделано на Views, которое, как я понял, сделано с нуля.

Так-то сторонние либы в репозитории хрома занимают больше места, чем остальные исходники браузера.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Я не особо разбирался в этом вопросе, скорее всего они и тему парсят и в WinAPI лазят для рисования видежетов

Может я сильно задержался на винде, но я в упор не понимаю, зачем кому-то нужно парсить msstyle. Оно же специально для винды убогой сделано, которая ничего другого не умеет. Типа «я смотрю, у вас тут одни калеки - возьму-ка и я себе костыль для приличия».
на винде есть системная uxtheme.dll со вполне стабильным API, которая выдает кодеру стили у удобноваримой форме:
https://docs.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthe...
Отсюда находим:
plugins\styles\windowsvista\qwindowsvistastyle.cpp
plugins\styles\windowsvista\qwindowsxpstyle.cpp
widgets\dialogs\qwizard_win.cpp

Если узнаешь ответ – является ли сущность QButton из Qt в Windows чем-то подобным – https://docs.microsoft.com/en-us/windows/win32/controls/create-a-button, как ты предполагаешь, дай об этом знать, самому интересно.

Отдельное окно Qt создается через CreateHandle, но всё, что находится в нем - это полностью родные Qt компоненты, не представленные объектом ядра винды. Меня это весьма удивило в первый раз, когда я увидел эту картину. С другой стороны - подход весьма правильный, посколько минимизирует обработку фейса в ядре, переводя ее в пользовательский режим. VCL тоже чем-то подобным балуется, хоть и весьма ограничено, поскольку виндовый common control вставить в иерархию контролов пользователського режима весьма проблематично.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Интересно, есть ли подобные языки, где тип переменной задаётся её именем по типу

Такое пробовали когда-то. В фортране имена, начинающиеся с i, j, ..., были целыми. В QBasic можно было самому задать правило типа «все имена, начинающиеся с буквы z, будут иметь тип Double».

И насколько такой синтаксис будет удобным

Это не синтаксис, это лексика, определяющая семантику. Идея не прижилась, да.

anonymous
()
Ответ на: комментарий от byko3y

на винде есть системная uxtheme.dll со вполне стабильным API, которая выдает кодеру стили у удобноваримой форме

Я просто не в курсе как там в данное время в Windows эти технологии называются: msstyle или uxtheme, можешь объяснить различия между ними? Если uxtheme современный и рекомендуется к использованию, действительно, почему бы и не заюзать его.

Отсюда находим

Именно на эти файлы я и дал линк анону, то бишь если бы мне требовалось поковыряться с темами винды для собственного тулкита, я бы смотрел туда. А что там отдаёт нужные мне параметры темы, uxtheme или msstyle это уже детали реализации.

но всё, что находится в нем - это полностью родные Qt компоненты, не представленные объектом ядра винды

То бишь у Qt просто отлично сделанная мимикрия на Windows, которая позволяет выглядеть ему практически нативно, так?

Благодарю за полезную информацию, есть пища для размышлений. Вот, например, в Qt стили windowsvista и macos платформозависимые, однако если дело обстоит так, как ты говоришь, можно сыэмулировать структуры, которые отдаются через OpenThemeData() в uxtheme и аналогичных API для macOS, что позволит перенести эти темы, например, на Linux с минимальной правкой кода. Было бы интересно заняться подобным. Вот только полезно ли это уже другой разговор.

EXL ★★★★★
()
Ответ на: комментарий от byko3y

С другой стороны - подход весьма правильный, посколько минимизирует обработку фейса в ядре, переводя ее в пользовательский режим.

Ну и к тому же он позволяет делать всякие нестандартные вещи, например менять у контролов стили без каких-либо конвертаций, которые были бы понятны сущности CreateWindow(... BS_DEFPUSHBUTTON ...). или же заниматься подобным: https://doc.qt.io/qt-5/qtwidgets-graphicsview-embeddeddialogs-example.html в своё время очень впечатлило такое, хотя применения особого оно не нашло.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Я просто не в курсе как там в данное время в Windows эти технологии называются: msstyle или uxtheme, можешь объяснить различия между ними? Если uxtheme современный и рекомендуется к использованию, действительно, почему бы и не заюзать его.

uxtheme - это либа, которая читает msstyle.

То бишь у Qt просто отлично сделанная мимикрия на Windows, которая позволяет выглядеть ему практически нативно, так?

Сами common controls через тот же uxtheme читают стили и рисуют их в окошках. Разница между родными контролами и пользовательскими заключается не во внешнем виде, не в функциях рисования - можно сделать так, что и common controls будут выглядеть «неродными». Разница - в использовании оконных механизмов, через которые производится разделение областей экрана, управление фокусом и вводом с клавиатуры, отправка сообщений, и построение иерархии из этих окошек.

если дело обстоит так, как ты говоришь, можно сыэмулировать структуры, которые отдаются через OpenThemeData() в uxtheme и аналогичных API для macOS, что позволит перенести эти темы, например, на Linux с минимальной правкой кода.

Вродь в инетах должны быть исходники XP - может там есть исходники и uxtheme.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Идея не прижилась, да

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

EXL ★★★★★
()
Ответ на: комментарий от byko3y

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

Мне в первую очередь бросается в глаза различный вид контролов или их поведение, отличное от стандартного. И здесь скорее всего разработчики Qt действительно вылизали свою тему, что этого практически не ощущается.

Вродь в инетах должны быть исходники XP - может там есть исходники и uxtheme.

Исходники наверное 2K, сомневаюсь что там есть uxtheme.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Это не совсем MacOS API, даже близко не MacOS API.
Возможность запуска приложений с macOS в Linux реализуется в проекте Darling, но в GUI оно так и не смогло.

Да, это не эмулятор, это просто API, собрал программу и скомпилировал и на Linux и на Mac и на Windows, как cygwin.

недавно решил попробовать впервые cygwin(как ни как лицензия теперь LGPL, а не GPL) и обнаружил, что gtk и qt проги собранные в cygwin требуют X11 сервер. Зато можно использовать версии qt и gtk которые уже не поддерживаются нативно. Типа qt 5.13 на Windows Vista, возможно и на XP пойдёт, есть люди кто хранит устаревший репозитарий cygwin: http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от EXL

Мне в первую очередь бросается в глаза различный вид контролов или их поведение, отличное от стандартного. И здесь скорее всего разработчики Qt действительно вылизали свою тему, что этого практически не ощущается.

Да, поведение другое. В семерке, например, сделали плавные переходы при наведении курсора в кнопках, или какое-нибудь контекстное меню с опциями ввода юникода - это уже мелкие фичи, которые нет в Qt, потому что делать больше нечего разрабам, кроме как вылизвать вид до степени слияния. Причем, в той же семерке есть common controls старые, которые этого не умеют, а выглядят как в XP.

byko3y ★★★★
()

Wine же не полностью совместим. В 2008 году я играл в Героев 4 под Wine, они Wine Desktop нормально работают, а в фулл скрине проблемы. А ещё иногда бывает, что диалог показывается позднее, чем нужно. В винде железно срабатывает, что если ты победил последнюю армию врага, то «Зелёный игрок уничтожен», а в линуксе ты разбил последнюю армию врага, и сообщение не появляется. Идёшь шахту захватил, и «Шахта теперь ваша, игрок зелёный уничтожен».

Попробовал в 2018-м. Ничего не изменилось.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

В винде железно срабатывает, что если ты победил последнюю армию врага, то «Зелёный игрок уничтожен», а в линуксе ты разбил последнюю армию врага, и сообщение не появляется. Идёшь шахту захватил, и «Шахта теперь ваша, игрок зелёный уничтожен».

Это баги в самой игре. Почитай, с чем приходилось сталкиваться разрабам винды для того, чтобы глючный софт после обновления не отваливался:
http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html
«Borland compiler came to depend on an existing bug, so their fix worked to preserve some of the bug's behaviour.»
«The specific idiot in this case is Office95, which likes to free a random pointer when you start Word95 from a desktop shortcut.»

Правило очень простое: если софт не работает под Wine, значит он плохо работает и под виндой.

byko3y ★★★★
()
Ответ на: комментарий от beaver
Win32 кросплатформенный api

Но ведь это говно мамонта, простите, а не апи. Зачем его в линух тянуть?

Вообще это единственный API который достаточно понятен чтобы новичёк смог на нём написать графическое приложение с циклом обработки сообщений.

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

Вообще это единственный API который достаточно понятен чтобы новичёк смог на нём написать графическое приложение с циклом обработки сообщений

Эм-м-м... давай сравнивать подобное с подобным: пользовательский фейс на common controls с главным циклом больше похож по устройству на приложение gtk или qt, с той лишь разницей, что common controls могут проходить через границы процессов, чего не может делать gtk или qt. Разрабатывалась такая модель изначально для всяких ActiveX, OLE, и прочей дряни, встраиваемой извне в приложение.

byko3y ★★★★
()
Ответ на: комментарий от meliafaro

Сам то пробовал сравнить разработку с Qt и Gtk под винду?

anonymous
()
Ответ на: комментарий от torvn77

Вообще это единственный API который достаточно понятен чтобы новичёк смог на нём написать графическое приложение с циклом обработки сообщений.

Што?

Код из MSDN под WinAPI:

#ifndef UNICODE
#define UNICODE
#endif 

#include <windows.h>

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE, PWSTR pCmdLine, int nCmdShow)
{
    // Register the window class.
    const wchar_t CLASS_NAME[]  = L"Sample Window Class";
    
    WNDCLASS wc = { };

    wc.lpfnWndProc   = WindowProc;
    wc.hInstance     = hInstance;
    wc.lpszClassName = CLASS_NAME;

    RegisterClass(&wc);

    // Create the window.

    HWND hwnd = CreateWindowEx(
        0,                              // Optional window styles.
        CLASS_NAME,                     // Window class
        L"Learn to Program Windows",    // Window text
        WS_OVERLAPPEDWINDOW,            // Window style

        // Size and position
        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

        NULL,       // Parent window    
        NULL,       // Menu
        hInstance,  // Instance handle
        NULL        // Additional application data
        );

    if (hwnd == NULL)
    {
        return 0;
    }

    ShowWindow(hwnd, nCmdShow);

    // Run the message loop.

    MSG msg = { };
    while (GetMessage(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return 0;
}

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
    case WM_DESTROY:
        PostQuitMessage(0);
        return 0;

    case WM_PAINT:
        {
            PAINTSTRUCT ps;
            HDC hdc = BeginPaint(hwnd, &ps);



            FillRect(hdc, &ps.rcPaint, (HBRUSH) (COLOR_WINDOW+1));

            EndPaint(hwnd, &ps);
        }
        return 0;

    }
    return DefWindowProc(hwnd, uMsg, wParam, lParam);
}

Код под WinForms:

class Program
{
    void Main()
    {
        var window = new System.Windows.Forms.Form();
        Application.Run(window);
    }
}

beaver
()
Ответ на: комментарий от beaver

WM_PAINT тут не обязателен, и в коде WinForms нет задания заголовка окна. Так-то можно функцию создания окна засунуть в отдельную библиотеку, ровно как и главный цикл, что и делает тот же MFC:

#include <afxwin.h>

class MFC_Tutorial_Window :public CFrameWnd
{
public:
    MFC_Tutorial_Window()
    {
        Create(NULL,"MFC Tutorial Part 1 CoderSource Window");
    }

};

class MyApp :public CWinApp
{
   MFC_Tutorial_Window *wnd; 
public:
   BOOL InitInstance()
   {
       wnd = new MFC_Tutorial_Window();
       m_pMainWnd = wnd;
       m_pMainWnd->ShowWindow(SW_SHOW);
       return TRUE;
   }
};

MyApp theApp

byko3y ★★★★
()
Ответ на: комментарий от beaver

Проблема в том, что короче не значит просще. На WinApi есть два раздельных загончика, один для создания окна и обработки сообщений, второй для отрисовки окна.

А вот где загончики в твоём коротком примере? Куда там добавлять код для отрисовки окна и куда для цикла сообщений? Этот код вообще не выглядит как имеющий циклы.

И даже если есть простое объяснение этого, то я в своё время понятного описания создания приложений в linux не нашёл.

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Хром использует GTK на никса, но на форточках у него своя либа

Посмотрел на исходники firefox:

https://hg.mozilla.org/mozilla-central/file/tip/widget/

https://hg.mozilla.org/mozilla-central/file/tip/widget/windows/nsWindow.cpp#l807

тоже своя либа.

Чем им кросплатформенные либы не угодили?

Браузеры поменьше вроде пользуются и норм:

Otter Browser - Qt5

Midori - Gtk3

fsb4000 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.