Здравствуйте, wamaco, Вы писали:

W>Уважаемые, скажите, а приложения под Windows все еще продаются?
W>Я имею ввиду, тех, у кого приложения Windows, основная статья дохода.
W>Интересно также про приложения под UWP.

Для дела/работы, B2B — продаются без проблем. Для развлекухи, B2C — по нолям, все ушли в веб, на планшеты/смартфоны

bnk>Для дела/работы, B2B — продаются без проблем. Для развлекухи, B2C — по нолям, все ушли в веб, на планшеты/смартфоны

Веб для мощных игр слабоват. Шутеры еще качают хорошо с торрентов. Стим конечно сжимается.

Здравствуйте, rean, Вы писали:

R>Винды еще тогда, когда книга появилась, даже в проектах не было.
R>Эта штука появилась раньше винды примерно на полгода.

Вы действительно полагаете, что от начала проектирования винды до выпуска рабочей версии могло пройти меньше года-двух?

deleted

Здравствуйте, rean, Вы писали:

R>Скриншоты говорят, что Винду передирали, наверняка, с GEM и с его предшественника.

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

deleted

Здравствуйте, Nuzhny, Вы писали:

N>А для меня Win32 — это ООП, причём более чистое, чем классы в С++

Хм. Очень глубокая мысль. Которая возможно даже действительно объясняет неудачи попыток заменить Win32 на что-то другое.

Здравствуйте, rean, Вы писали:

R>По сравнению с тем что пилили тогда, и Microsoft и Apple, да и другие подобные энтузиасты с паяльником делать калькуляторы тех времен, выглядели просто подростками рядом с профи.

Ага, и значение синуса достигало четырех.

Здравствуйте, wamaco, Вы писали:

W>Уважаемые, скажите, а приложения под Windows все еще продаются?
Ещё продаются. ИМХО больше b2b и только если очень нужные и там куда недошел веб.

Но вот я вижу, что на западе новые проекты в основном веб и иногда веб+мобильные.
Причём переход начался лет 10 так назад. Это было видно скажем по форуму Джоэля Business of software.

И если тогда веб казался почти блажью, то теперь видно, что
это был объективный процесс.

Здравствуйте, rean, Вы писали:

R>Я пытался сделать самодельную легкую прослойку для Win32 и для мака, но увяз в деталях и недокументированных особенностях,
R>какие не найти в интернете. Все было путем проб и ошибок. Мог показывать окна, меню, простейшие контролы.
R>Расчет был на легковесность прослойки, чтобы по-максимуму использовать особенности систем. Но пришлось бросить этот проект
R>из-за трудоемкости и начавшихся проблем с падением доходов от шаревары на винде. А так бы, уже давно все закончил и имел портабельные
R>программы.

Хочу поделиться нашим опытом в разработке кроссплатформенных приложений: в свое время писали продукты на Delphi, от которого стало дурно пахнуть, и решили переписали свой флагманский продукт на C++, причем изначально в архитектуру были заложена кроссплатформенная архитектура:
1. Для ядра используется только стандартный STL.
2. Для хранения строк используется обычный std::string в кодировке UTF8
3. Разработан небольшой набор собственных API, которые общаются с операционкой (все строковые параметры и результаты функций тоже UTF8). Например для Windows внутри API идет конвертация в wstring и обратно.
4. Для GUI выбрали QT, с которым пришлось немного пот...ся при разработке стилей под разные операционки (подогнать отступы в виджетах и т.п.), но это разовый гемор.

В результате имеем один набор исходников под Windows/OSX/Linux с минимальными усилиями по добавлению новых API в кроссплатформенный слой.

V>4. Для GUI выбрали QT, с которым пришлось немного пот...ся при разработке стилей под разные операционки (подогнать отступы в виджетах и т.п.), но это разовый гемор.

пожалей мои глаза, пропиши под макосью в Info.plist вот это:

<key>NSHighResolutionCapable</key>
<string>True</string>

V>В результате имеем один набор исходников под Windows/OSX/Linux с минимальными усилиями по добавлению новых API в кроссплатформенный слой.

полностью на Qt так и не решились? без std::string?

Здравствуйте, rean, Вы писали:

R>Где-то параллельно началу этих времен на микро-компьютерах размером в трехкомнатную квартиру тогда дербанили диалекты Unix.

Не надо про 3-х комнатную хату:
https://ru.wikipedia.org/wiki/PDP-11
Эта штука, на которой разрабатывались Си & Unix, была с большой платяной шкаф

R>Сейчас практически все, на чем основана работа операционных систем, компиляторов, сетей, многозадачности и прочего, основана на идеях из 60-х годов.

Идеи, лёгшие в основу Java и .NET, — всё таки из 80/90-х годов.
Применение ООД и ООП — продвигалось с начала 80-х.
Сейчас реализуется много проектов, идеи которых родились в начале/середине 2000-х.

Здравствуйте, drVanо, Вы писали:

V>2. Для хранения строк используется обычный std::string в кодировке UTF8
V>3. Разработан небольшой набор собственных API, которые общаются с операционкой (все строковые параметры и результаты функций тоже UTF8).

Почему не сразу в UTF-16? Тогда, как минимум, под виндой не нужна конвертация, и вся обработка идет без закидонов. А ежели куда надо выгрузить в UTF-8, то это всяко проще, чем всю обработку на него затачивать.

Здравствуйте, Matrix_Failure, Вы писали:

M_F> И если тогда веб казался почти блажью, то теперь видно, что это был объективный процесс.

В том виде, в каком он сейчас есть, это до сих пор блажь. Ну не должен браузер выполнять роль виртуальной машины для приложений с заранее неизвестным поведением и неограниченными требованиями к ресурсам. В HTML давно надо было оставить какой-нибудь среднефункциональный огрызок JS, с жестким ограничением по ресурсам, чтоб не мешал серфингу, а веб-приложения исполнять в отдельном VM Executive, навроде Dalvik/ART, хоть встроенном в ОС, хоть ставящемся сбоку.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Почему не сразу в UTF-16? Тогда, как минимум, под виндой не нужна конвертация, и вся обработка идет без закидонов. А ежели куда надо выгрузить в UTF-8, то это всяко проще, чем всю обработку на него затачивать.

Потому что UTF8 — родная кодировка для OSX/Linux и для вызовов API никакая конвертация не требуется.

P.S. Например вот так:

namespace os
{
...
HANDLE FileCreate(const char *name, uint32_t mode)
{
#ifdef VMP_GNU
    int flags;

    switch (FILE_OPEN_MODE(mode)) {
    case fmOpenRead:
        flags = O_RDONLY;
        break;
    case fmOpenWrite:
        flags = O_WRONLY | O_TRUNC;
        break;
    case fmOpenReadWrite:
        flags = O_RDWR;
        break;
    default:
        return INVALID_HANDLE_VALUE;
    }

    if (mode & fmCreate)
        flags |= (O_CREAT | O_TRUNC);

    return reinterpret_cast<HANDLE>(open(name, flags, (flags & O_CREAT) ? S_IRUSR | S_IWUSR | S_IXUSR | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH : 0));
#else
    uint32_t desired_access, share_mode;

    switch (FILE_OPEN_MODE(mode)) {
    case fmOpenRead:
        desired_access = GENERIC_READ;
        break;
    case fmOpenWrite:
        desired_access = GENERIC_WRITE;
        break;
    case fmOpenReadWrite:
        desired_access = GENERIC_WRITE | GENERIC_READ;
        break;
    default:
        return INVALID_HANDLE_VALUE;
    }

    switch (FILE_SHARE_MODE(mode)) {
    case fmShareExclusive:
        share_mode = 0;
        break;
    case fmShareDenyWrite:
        share_mode = FILE_SHARE_READ;
        break;
    case fmShareDenyRead:
        share_mode = FILE_SHARE_WRITE;
        break;
    case fmShareDenyNone:
        share_mode = FILE_SHARE_READ | FILE_SHARE_WRITE;
        break;
    default:
        return INVALID_HANDLE_VALUE;
    }

    return CreateFileW(FromUTF8(name).c_str(), desired_access, share_mode, NULL, (mode & fmCreate) ? CREATE_ALWAYS : OPEN_EXISTING, 0, NULL);
#endif
}

Здравствуйте, ov, Вы писали:

V>>4. Для GUI выбрали QT, с которым пришлось немного пот...ся при разработке стилей под разные операционки (подогнать отступы в виджетах и т.п.), но это разовый гемор.

ov>пожалей мои глаза, пропиши под макосью в Info.plist вот это:

ov>

ov><key>NSHighResolutionCapable</key>
ov><string>True</string>
ov>

Спасибо, попробуем.

V>>В результате имеем один набор исходников под Windows/OSX/Linux с минимальными усилиями по добавлению новых API в кроссплатформенный слой.

ov>полностью на Qt так и не решились? без std::string?

Qt нужно только в GUI версии (ессно с использованием Qt-ных строк). Само ядро, с которым работает GUI и консольная версии, написано на std::string.

Здравствуйте, drVanо, Вы писали:

V>Потому что UTF8 — родная кодировка для OSX/Linux и для вызовов API никакая конвертация не требуется.

Хм, а как у них с эффективностью обработки текстов в мультибайтовой кодировке? В MSVC всякие _mbXXX тормозят изрядно.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Почему не сразу в UTF-16?
Тогда почему не UTF-32?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> V>Потому что UTF8 — родная кодировка для OSX/Linux и для вызовов API никакая конвертация не требуется.
ЕМ> Хм, а как у них с эффективностью обработки текстов в мультибайтовой кодировке? В MSVC всякие _mbXXX тормозят изрядно.

Смотря что ты подразумеваешь под "обработкой текстов". Для большинства программ нет никакой разницы в какой кодировке у тебя лежат данные в char* потому что тебя интересует только размер буфера памяти и работа ведется с абстрактными байтами.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Тогда почему не UTF-32?

А смысл? Для чего нынче не хватает UTF-16?