Преимущества графических интерфейсов.

3-62> Нет таких вопросов. Уровень именно что студенческий.
Нифига. В общем случае задача построения UI - не студенческий уровень.
Я более скажу - у нас на матмехе тетка кандидатскую по UI и базе защитила.

yacc>> В рамках учебных курсов подавляющего количества вузов нет дисциплины по UI.
3-62> Тот кто учится, а не "прослушивает курс" - факультативно доберет информацию.
Нет факультативов. Бери книгу сам и читай сам и разбирайся сам.
Тебе даже задачу не поставят сделать UI.

yacc>> И не было толком ее в 90-е, когда писали под ДОС.
3-62> Была и тогда. Да, поискать надо было. Но найти - было не невозможно.
Еще раз по буквам: в П о д а в л я ю щ е м б о л ь ш и н с т в е В У З о в.
Никто этот UI проектировать не учил кроме книг типа ТурбоВижн где создание UI и было целью.
И вдвойне никто этому не учил делать через 10 прерывание через выставление позиции курсора и символа по курсору кроме редких исключений в рамках личной инициативы.

yacc> Нифига. В общем случае задача построения UI - не студенческий уровень.

И что в ней такого сложно-профессорского уровня?

yacc> Я более скажу - у нас на матмехе тетка кандидатскую по UI и базе защитила.

Не довод.

yacc> Еще раз по буквам: в П о д а в л я ю щ е м б о л ь ш и н с т в е В У З о в.

И что?
Огрехи системы образования.

yacc> И вдвойне никто этому не учил делать через 10 прерывание через выставление позиции курсора

Полагаете в "турбовижн" это делается иначе, не через прерывание BIOS?

3-62> И что в ней такого сложно-профессорского уровня?
А вот.
Не, наговнокодить UI то ума не надо...

yacc>> Еще раз по буквам: в П о д а в л я ю щ е м б о л ь ш и н с т в е В У З о в.
3-62> И что?
3-62> Огрехи системы образования.
Все правильно - пользователям курсы по созданию UI нахрен не сдались.
Особенно по прерываниям на ДОС.

3-62> Полагаете в "турбовижн" это делается иначе, не через прерывание BIOS?
Пипец...

Сильно иначе!

yacc> Не, наговнокодить UI то ума не надо...

Вы уж определитесь с мнением.
Вижу что тезис о том, что незнание субъектом таблицы умножения, делает уровень задачи 7*8=? академическим, вы больше не используете.

xab>> 1. Пользовательские интерфейсы на порядок быстрее и проще разрабатывать.
Татарин> Настолько дикое и противоположное реальности заявление, что даже не знаешь, чего тут опровергать.
Татарин> Ты вообще WinAPI видел, минимальную прогу под винду когда-нить сам с нуля писал?

Я разрабатывал приложения под WinAPI и хорошо помню что такое хендлеры, обработчики событий, контексты отображения и прочая хрень

Татарин> Я-то, вообще, под чистый ВинАПИ интерфейсы ещё успел попрогать...

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

Татарин> Однако, имеют ли эти возможности ценность для конечного пользователя даже сейчас, после 30 лет развития парадигмы - вопрос во многих случаях неоднозначный.

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

xab>>> 1. Пользовательские интерфейсы на порядок быстрее и проще разрабатывать.
Татарин>> Настолько дикое и противоположное реальности заявление, что даже не знаешь, чего тут опровергать.
Татарин>> Ты вообще WinAPI видел, минимальную прогу под винду когда-нить сам с нуля писал?
xab> Я разрабатывал приложения под WinAPI и хорошо помню что такое хендлеры, обработчики событий, контексты отображения и прочая хрень
...
xab> С тех пор много воды утекло и появилось множество других средств разработки.
Ну так вернись в контекст разговора: изначальное заявление было таким "появление Винды сделало все остальные интерфейсы (и компы, в них неспособные) мгновенно устаревшими".

Ну где там в момент появления Винды было "упрощение"-то? Или ты вслед за yacc будешь утверждать, что вот со всей этой хренью UI было легче на тот момент создать под Винду, чем под ДОС?

Татарин>> Однако, имеют ли эти возможности ценность для конечного пользователя даже сейчас, после 30 лет развития парадигмы - вопрос во многих случаях неоднозначный.
xab> Тупо не было возможности разместить на одном экране и 10-й части информации.
xab> Тупо картинку и текст на одном экране разместить было огромной проблемой.
Это никак не связано с Виндой как таковой.
По бОльшей части своей мы обязаны этому радикально выросшему разрешению экранов. Понятное дело, что на моём 27" 4к экране поместится ГОРАЗДО больше информации, чем когда-то на текстовом экране 80х25 символов (или в графике 640х480 VGA, если уж на то пошлО).
Но Винда-то тут при чём?

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

yacc> Если кто забыл как писать в дос на С то могу очень легко напомнить - вот аналогичное надо было написать самому:
Я, кстати, писал.
BGI был ну очень медленный, а альтернатив доступных не было (у меня в те годы).
Ну и 320х200 VGA-256 для игрушек (что очень хотелось), BGI не поддерживал. , чисто аппаратно, без какого-либо БИОС.
Да, с VGA и EGA требовалась довольно муторная возня с регистрами, но пишется-то это один раз (и может быть, и не тобой).

yacc> И потом подобное
yacc> while (!kbhit())
yacc> ch = getch();
yacc> switch (ch)
yacc> {
yacc> case 0x3b00: / * F1 * /
yacc> break;
yacc> case 0x4800: / * up arrow * /
yacc> / * .... * /
yacc> }
Ну так это делается один раз. В библиотеке, в потрохах. А в винде - каждый раз в каждом хендлере, даже не один раз на программу.

Татарин> Я, кстати, писал.
Я тоже, точнее подсмотрел рецепт в журнале Монитор и взял необходимое подмножество, набивал руками и отлаживал.

Татарин> Да, с VGA и EGA требовалась довольно муторная возня с регистрами, но пишется-то это один раз (и может быть, и не тобой).
Оно в принципе для любых подобных приложений пишется один раз.
Правда на N-м приложении может легко найтись незамеченный баг или ситуация, которую ты просто не релизовал.

Татарин> Ну так это делается один раз. В библиотеке, в потрохах. А в винде - каждый раз в каждом хендлере, даже не один раз на программу.
И в винде один раз - точно также.

Хендлеры никуда не деваются и в Турбо Вижн.

Но вот тут винда уже начинает выигрывать - диалог там можно создать в визуальном редакторе.
В дос - рисуй по клеточкам и только потом программируй либо запустил/подправил( скажем комбобокс подвинул ибо смотрится хреново)/скомпилировал/запустил/цикл по правкам.
И вот тут турбо паскаль в ДОС сурово выигрывал у борландовского же С++ скоростью.

Татарин>> Ну так это делается один раз. В библиотеке, в потрохах. А в винде - каждый раз в каждом хендлере, даже не один раз на программу.
yacc> И в винде один раз - точно также.
Нет. Если ты в окне не подписался на маус_мув, то ты его и не получишь. Не получишь - не обработаешь, не передашь детям (в смысле, дочерним окнам). То есть, ты должен (как минимум, был, на том уровне производительности) отслеживать события, которые требуются элементам и обрабатывать релевантные, и менять этот список при изменении состава элементов. И всегда держать в уме возможный порядок прихода и обработки событий (см. пример выше с обновляемым объектом).

Свой кастомный элемент или сложный ЮИ в винде - это много геммороя, причём, тут именно что зависимость очень нелинейная: вроде как в обычном диалоге кода много, но приемлимо... а вот чуть в сторону от стандарта - и понеслось г**но по кочкам... Особенно, в первых ВинАпи.

yacc> В дос - рисуй по клеточкам и только потом программируй либо запустил/подправил( скажем комбобокс подвинул ибо смотрится хреново)/скомпилировал/запустил/цикл по правкам.
Затраты времени программиста на это конкретно - вообще ни о чём, в абсолютном большинстве случаев можно пренебречь. Да и были в ДОС-средах и развитых библиотеках там приблуды для конструирования диалогов, в том числе - и визуальные, мышкой (в том же ФоксПро).

Татарин> Нет. Если ты в окне не подписался на маус_мув, то ты его и не получишь.
Большинству пользователей это не нужно - ставить какие-то хуки.
И ты просто встраиваешься в обработку.

По умолчанию эта процедура такая
LRESULT CALLBACK WndProc(HWND hwnd, UINT Message, WPARAM wparam,LPARAM lparam)
{
if (Message == WM_DESTROY )
{
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hwnd,Message,wparam,lparam);
}

И тебе надо вставить туда твое например так
LRESULT CALLBACK WndProc(HWND hwnd, UINT Message, WPARAM wparam,LPARAM lparam)
{
if (Message == WM_DESTROY )
{
PostQuitMessage(0);
return 0;
}
else
{
MyLibraryAlreadyImplemented(hwnd,Message,wparam,lparam);
}
return DefWindowProc(hwnd,Message,wparam,lparam);
}




Татарин> Не получишь - не обработаешь, не передашь детям (в смысле, дочерним окнам). То есть, ты должен (как минимум, был, на том уровне производительности) отслеживать события, которые требуются элементам и обрабатывать релевантные
Еще раз - у модального диалога - своя процедура. Отдельная от той что выше.
И никакой маус мув для работы с диалогами нахрен не нужет.

Татарин> Свой кастомный элемент или сложный ЮИ в винде - это много геммороя
В ДОС да в графике это конечно же проще, ага
Учитывая что библиотек типа Турбо Вижн для работы в SVGA в DOS вообще не было.

yacc>> В дос - рисуй по клеточкам и только потом программируй либо запустил/подправил( скажем комбобокс подвинул ибо смотрится хреново)/скомпилировал/запустил/цикл по правкам.
Татарин> Затраты времени программиста на это конкретно - вообще ни о чём
Да нихрена.
Зависит от программы.
Если программа достаточно простая то 90% времени в Дос ты убьешь на это ручное написание интерфейса.

Татарин>Да и были в ДОС-средах и развитых библиотеках там приблуды для конструирования диалогов, в том числе - и визуальные, мышкой (в том же ФоксПро).
В ДОС средах, но не для ЯП универсального.
Ровно тоже самое в Фоксах в виндах - тебе вообще не надо знать что какие-то там внд_проц есть и хуки.

Татарин>> Нет. Если ты в окне не подписался на маус_мув, то ты его и не получишь.
yacc> Большинству пользователей это не нужно - ставить какие-то хуки.
Понимаешь, "большинство" (кстати, не пользователей, а программистов - важно) - это очень мутное понятие. Задача расширения стандартных контролов в первых виндах (до 95+) была довольно типична, потому что на деле возникала при любом шаге в сторону от красивых примеров из учебника. В 95/2000 и далее набор контролов заметно увеличили и сами контролы стали более функциональны, острота проблемы несколько спала. Но не то чтоб проблема ушла совсем.

yacc> И ты просто встраиваешься в обработку.
Да-да. "Просто встраиваешься".

yacc> Еще раз - у модального диалога - своя процедура.
А при чём тут именно модальный-то диалог? Ну, допустим, даже модальный - так оно проблему усугубляет: у каждого модального диалога в общем случае свой обработчик, и в каком-то используются одни кастомные элементы, а в другом другие.

Татарин>> Свой кастомный элемент или сложный ЮИ в винде - это много геммороя
yacc> В ДОС да в графике это конечно же проще, ага
Ну да. Пробовал и то, и то. Не то что много, а, сказал бы, МНОГО проще.

У меня была просто таки идеальная возможность сравнить: софт для спектрографа меня потом (много лет после) просили переписать... оценив объёмы на плюсах (а ведь к тому моменту я уже писал коммерцию под винду на плюсах), я просто плюнул и взял Дельфи.
Да, с Дельфями всё (по части UI) было красиво и приятно. Но с учётом всего взяло столько же времени, что и под ДОС (а ведь ТЗ-логика-функционал, что чуть ли не половина программы уже были готовы, все пути хожены)... Это что угодно, но НЕ показатель простоты.

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

yacc> Учитывая что библиотек типа Турбо Вижн для работы в SVGA в DOS вообще не было.
Были платные. Да, тут приходилось самому. Собссно, вот это и было реальной киллер-фичей Винды: стандартизация работы с графикой, за которую разработчики и простили ей всё остальное, а пользователи реально были благодарны.
Потому что до Винды каждая прога типа Автокада или 3д-студии-потомставшейМаксом тащили с собой целый ворох драйверов, и этого, ессно, всё равно не хватало, потому что аппаратура быстро разнообразилась. А появление Винды как стандарта на драйвера подстегнуло разработку разнообразной аппаратуры. Вот это была реально сильная её сторона.
Но - собссно - если бы развивались нормально ДОС и БИОС (вот прям как задумано), кто ж мешал делать всё это на их уровне? Концепция графических драйверов, встроенных в видеокарту (в виде ПЗУ) и изначально работающих бесконфликтно и оптимально - это как-то даже посильнее, чем всё, что было впоследствии (вплоть даже до текущего времени).

yacc> Если программа достаточно простая то 90% времени в Дос ты убьешь на это ручное написание интерфейса.
Ну да. Но при этом всё равно потрачу меньше времени чем с виндой, а результат будет выглядеть куда более цельно и проще для поддержки, чем размотанные сопли хендлеров в винде. Если же интерфейс потребует чего-то кастомного (что ну очень часто в программе, которая что-то делает, а не просто обеспечивает ввод), то разница становится десятки раз запросто. Потому что реализация одного кастомного элемента под винду может занять больше времени, чем возня со всей досовской прогой целиком.

yacc> В ДОС средах, но не для ЯП универсального.
Были-есть библиотеки. А если под что не было, то можно было их сделать. Написание библиотек интерфейсов под ДОС - джуновская задача.

Написание таких библиотек под винду, которые реально упрощали бы написание программ - задача эпической сложности, с которой не сразу справился сам Микрософт. Причины - см. выше.
Как бы вроде всё хорошо и понятно, но как только начинаешь влезать в детали и реально писать, начинается ад по типу "дальше в лес больше дров". И уж кого-кого, а МС на тот момент в недостатке умов и компетенций (в винде-то, ага) обвинить уж никак было нельзя.

ть какие-то хуки.
Татарин> Задача расширения стандартных контролов в первых виндах (до 95+) была довольно типична, потому что на деле возникала при любом шаге в сторону от красивых примеров из учебника.
Заметь, ты молчишь про расширение контролов в ДОС под турбо вижн, а там, внезапно, тебя ждет ровно тоже самое - надо лезть в потроха кода.

Татарин> В 95/2000 и далее набор контролов заметно увеличили и сами контролы стали более функциональны
В турбовижене под ДОС их палитра была победнее чем в 3.1

Татарин> Да-да. "Просто встраиваешься".
Как и везде в событийно-управляемых - и в том же ТурбоВИжн - ТОЖЕ.

Татарин> А при чём тут именно модальный-то диалог? Ну, допустим, даже модальный - так оно проблему усугубляет: у каждого модального диалога в общем случае свой обработчик
И это правильно.

yacc>> В ДОС да в графике это конечно же проще, ага
Татарин> Ну да. Пробовал и то, и то. Не то что много, а, сказал бы, МНОГО проще.
В ДОСе все писать руками, ага.


Татарин> У меня была просто таки идеальная возможность сравнить: софт для спектрографа меня потом (много лет после) просили переписать... оценив объёмы на плюсах (а ведь к тому моменту я уже писал коммерцию под винду на плюсах), я просто плюнул и взял Дельфи.
Которая внезапно просто оборачивает за тебя эти же оконные процедуры.

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

А если пишешь сам - то в досе создавай обертку над kbhit и прерыванием 10.
Если забыл, то это называлось "системное программирование" и вовсе не для джунов.
И плюс работа на это "свое" - но ты ее упорно считать не хочешь.

В виндах при стандартных контролах - все есть - бери и используй.
Кастомные контролы далеко не всегда были нужны. И на это уже способен джун с книгой и сэмплами со студией.

Татарин> Но - собссно - если бы развивались нормально ДОС и БИОС (вот прям как задумано), кто ж мешал делать всё это на их уровне? Концепция графических драйверов, встроенных в видеокарту (в виде ПЗУ) и изначально работающих бесконфликтно и оптимально - это как-то даже посильнее, чем всё, что было впоследствии (вплоть даже до текущего времени).
Юзерам неинтересно системное программирование - лезть в прерывания.


yacc>> Если программа достаточно простая то 90% времени в Дос ты убьешь на это ручное написание интерфейса.
Татарин> Ну да. Но при этом всё равно потрачу меньше времени чем с виндой
Гораздо больше.
На виндах взял готовый сэмпл да доделал - все!

Татарин>Если же интерфейс потребует чего-то кастомного (что ну очень часто в программе, которая что-то делает, а не просто обеспечивает ввод)
Кастомный интерфейс далеко не всегда нужен.
И на дос сам все будешь рисовать - в память адаптера ассемблерным кодом.

Татарин> Были-есть библиотеки. А если под что не было, то можно было их сделать. Написание библиотек интерфейсов под ДОС - джуновская задача.
Фик тебе!
Залезть в ассемблер называется "системное программирование" - оно всегда так для ЭВМ называлось
И это нихрена не джун.

От того, что ТЫ лазил там в потрохах спектрума и что-то там на кодах z80 для фана ваял, НЕ следует что любой джун туда полезет и что любой джун системные прерывания знает наизусть.
Возиться с прерываниями именно что задача для системного программиста.
Прикладной, а джун именно такой, вообще не в курсах что там в потрохах.

yacc> Заметь, ты молчишь про расширение контролов в ДОС под турбо вижн, а там, внезапно, тебя ждет ровно тоже самое - надо лезть в потроха кода.
Нет, не то же самое. Там - просто по структуре построения программы - гораздо проще изолировать код компонента и куда проще сам компонент.

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

yacc> Которая внезапно просто оборачивает за тебя эти же оконные процедуры.
Она ещё много-много всего делает. И вот ТОГДА только создание интерфейсов в Винде стало сравнимо (или даже легче, если простое брать). О чём я и.

yacc> Кастомные контролы далеко не всегда были нужны. И на это уже способен джун с книгой и сэмплами со студией.
Время не сопоставимо.

Татарин>> Но - собссно - если бы развивались нормально ДОС и БИОС (вот прям как задумано), кто ж мешал делать всё это на их уровне? Концепция графических драйверов, встроенных в видеокарту (в виде ПЗУ) и изначально работающих бесконфликтно и оптимально - это как-то даже посильнее, чем всё, что было впоследствии (вплоть даже до текущего времени).
yacc> Юзерам неинтересно системное программирование - лезть в прерывания.
Да чушь это. Всегда под основные ЯВУ были библиотеки-обёртки, собссно, потому они и ЯВУ.
Как будто ты лез в БИОС за выводом строки, а не подключал stdio и писал "printf();"
bios.h - это вот что такое? Оно и есть.

Но МС решила продвигать Винду (за что её хейтили потом поколениями, ибо в Винде много сделано неудачно и как времянка). Ну, в итоге как-то куда-то вывезли... и даже не факт, что OS/2 была бы как-то сильно лучше.

Но могли бы и довести до ума ДОС (да хоть до минимального уровня "я не пере-CP/M, а недоUnix!").
Собссно, чего тогда все жаждали и ждали. Лет так десять... до Вин2000, примерно. Да и потом больше свыклись и притерпелись, чем исчезла нужда в нормальной ОС без графической среды.

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

Так что не надо про "вышла Винда, все обречены".

yacc> От того, что ТЫ лазил там в потрохах спектрума и что-то там на кодах z80 для фана ваял, НЕ следует что любой джун туда полезет и что любой джун системные прерывания знает наизусть.
yacc> Возиться с прерываниями именно что задача для системного программиста.
yacc> Прикладной, а джун именно такой, вообще не в курсах что там в потрохах.
Вообще говоря, и не следует, и нет - любой прикладной программист под ДОС должен бы знать системные прерывания ДОС. Они для того и сделаны. Это именно прикладной, не системный уровень.

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

Системный уровень - это когда ты пишешь функции системы, прости за банальность. А не когда используешь её.

Татарин> Ладно, тут бесполезно говорить: пока не тыкнешься сам - не поймёшь.
Я и так пробовал так что знаю.
И это я молчу про контролы типа рич эдит или просто эдит с файлами, которые в винде в целом штатные.

yacc>> Которая внезапно просто оборачивает за тебя эти же оконные процедуры.
Татарин> Она ещё много-много всего делает. И вот ТОГДА только создание интерфейсов в Винде стало сравнимо (или даже легче, если простое брать). О чём я и.
Оно было легче еще в VB 1.0 под ту же самую 3.1.


yacc>> Юзерам неинтересно системное программирование - лезть в прерывания.
Татарин> Да чушь это. Всегда под основные ЯВУ были библиотеки-обёртки, собссно, потому они и ЯВУ.
Внезапно для TUI никогда не было штатных оберток.
Ну до турбо вижн.
А у других компиляторов - а их дофига было типа Lattice, Watcom, Zortech, TopSpeed - вообще не было никаких турбовижнов

Татарин> Как будто ты лез в БИОС за выводом строки, а не подключал stdio и писал "printf();"
Татарин> bios.h - это вот что такое? Оно и есть.
Тебе напомнить что там в этом файле было ?
А было там вот что

bioscom
biosdisk
biosequip
bioskey
biosmemory
biosprint
biostime

 

т.е. НИЧЕГО что могло бы тебе помочь с TUI причем этот файл - не соответствует ANSI C
равно как и файл dos.h нестандартный, но для системных программистов - именно его надо было брать для 10h

Татарин> Но МС решила продвигать Винду (за что её хейтили потом поколениями, ибо в Винде много сделано неудачно и как времянка).
Надеюсь, ты сидишь в ДОС под Lynx сейчас ?

Татарин> Так что не надо про "вышла Винда, все обречены".
Как вышла видна так все стали отказываться от ДОСа последовательно.

Татарин> Вообще говоря, и не следует, и нет - любой прикладной программист под ДОС должен бы знать системные прерывания ДОС.
Голимая чушь

Татарин>Они для того и сделаны. Это именно прикладной, не системный уровень.
Прерывания сделаны для системных программистов.
Прикладной мог вообще не знать что они существуют.
Посчитать условно Рунге-Кутта - никаких нахрен прерывания знать НЕ НАДО.
Как и обработать тексты логов, скажем.

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

Татарин> Системный уровень - это когда ты пишешь функции системы, прости за банальность. А не когда используешь её.
Любая работа с железом кроме стандартных библиотек = системный программист.

Татарин>> Ладно, тут бесполезно говорить: пока не тыкнешься сам - не поймёшь.
yacc> Я и так пробовал так что знаю.
Просто машу рукой...

yacc> yacc>> Юзерам неинтересно системное программирование - лезть в прерывания.
Татарин>> Да чушь это. Всегда под основные ЯВУ были библиотеки-обёртки, собссно, потому они и ЯВУ.
yacc> Внезапно для TUI никогда не было штатных оберток.
Штатных не было, но при чём тут прерывания-то?

yacc> А у других компиляторов - а их дофига было типа Lattice, Watcom, Zortech, TopSpeed - вообще не было никаких турбовижнов
Ох, да ты гонишь же... Ну при чём тут компилятор-то? А библиотек была масса под С++, и даже купить можно было. Что, думаешь, в том же Клиппере или ФоксПро без неё справились? Другое дело, что не бесплатно.

Татарин>> Как будто ты лез в БИОС за выводом строки, а не подключал stdio и писал "printf();"
Татарин>> bios.h - это вот что такое? Оно и есть.
yacc> Тебе напомнить что там в этом файле было ?
yacc> А было там вот что
yacc> т.е. НИЧЕГО что могло бы тебе помочь с TUI
Ну вывод текста там, конечно, был. Могли бы и графику сделать: перевод в режим, базовые графические примитивы - в общем, всё то, что должен делать драйвер. Как БИОС и использовался вне графики, как и мыслился во времена, когда его ещё адекватно поддерживали.
Но не сделали, увы.

Татарин>> Но МС решила продвигать Винду (за что её хейтили потом поколениями, ибо в Винде много сделано неудачно и как времянка).
yacc> Надеюсь, ты сидишь в ДОС под Lynx сейчас ?
Нет, конечно. Зачем?
Но вот ВиндовсЕмбеддед я помню ну о-очень хорошо... И вот зачем оно было надо-то, уродство порезанное до бОльшего уродства чтобы не использовать недоразвитое уродство?
Всё-таки насколько проще, чище и "честнее" были устроены системы, которые сразу проектировались под свои задачи - хоть та же CP/M, хоть тот же Юникс.

Татарин>> Так что не надо про "вышла Винда, все обречены".
yacc> Как вышла видна так все стали отказываться от ДОСа последовательно.
Вот вообще даже близко не стояло. Тут, конечно, частично причиной неудачность Винды (даже как концепции - переоболочка, недоОС), но всё равно... очень сложный, тяжёлый был процесс...

yacc>> Внезапно для TUI никогда не было штатных оберток.
Татарин> Штатных не было, но при чём тут прерывания-то?
А ты в турбовижн никогда не залезал ?
Не в курсе что курсор там через то же 10 прерывание позиционировался либо самостоятельным кодом прямо в память видеоадаптера ? ( 10-е считалось медленным )
Так что если делать аналогичное самому - делать тоже самое.

yacc>> А у других компиляторов - а их дофига было типа Lattice, Watcom, Zortech, TopSpeed - вообще не было никаких турбовижнов
Татарин> Ох, да ты гонишь же... Ну при чём тут компилятор-то? А библиотек была масса под С++, и даже купить можно было.
Каких библиотек ? Кто купит? университет ?
К слову, в виндах тебе также никто не мешал купить контролы, а не париться с OWNERDRAW и хуками на мышь - чего же ты не купил?

Татарин>Что, думаешь, в том же Клиппере или ФоксПро без неё справились? Другое дело, что не бесплатно.
И там лезли в прерывания или прямо в видеопамять - под дос именно так надо было делать. Потому что сама ДОС вообще не предоставляла подобной работы - 10h это биос прерывание - MS ничего не сделал чтобы работать с TUI в ДОС.

Татарин> Ну вывод текста там, конечно, был. Могли бы и графику сделать: перевод в режим, базовые графические примитивы - в общем, всё то, что должен делать драйвер. Как БИОС и использовался вне графики, как и мыслился во времена, когда его ещё адекватно поддерживали.
КТО бы сделал ? Производители железа т.е. BIOS ? Оно им надо ?

yacc>> Надеюсь, ты сидишь в ДОС под Lynx сейчас ?
Татарин> Нет, конечно. Зачем?
Ты уж у нас такой хейтер графики в пользу текста - линкс и сейчас есть, к слову.

Татарин> Всё-таки насколько проще, чище и "честнее" были устроены системы, которые сразу проектировались под свои задачи - хоть та же CP/M, хоть тот же Юникс.
Помнится даже был анекдот тех времен :
"
1: Говорят ты тут программу пишешь, а какой у нее будет интерфейс ?
2: как у Юникс
1: А, ну значит никакого.
"
В СР\М в целом надо было бы делать также как ДОС - биос или видеопамять напрямую.

yacc>> Как вышла видна так все стали отказываться от ДОСа последовательно.
Татарин> Вот вообще даже близко не стояло. Тут, конечно, частично причиной неудачность Винды (даже как концепции - переоболочка, недоОС), но всё равно... очень сложный, тяжёлый был процесс...
Винда сняла гемор с разработчиков, взяв драйвера на себя.
После ДОС, когда я через 10h ставил курсор, я более в виндах в ассемблер и прерывания никогда не лез.

Татарин>> Вообще говоря, и не следует, и нет - любой прикладной программист под ДОС должен бы знать системные прерывания ДОС.
yacc> Голимая чушь
Просто руками развожу. Опять сочетание незнания с самоуверенностью.

Татарин>>> Вообще говоря, и не следует, и нет - любой прикладной программист под ДОС должен бы знать системные прерывания ДОС.
yacc>> Голимая чушь
Татарин> Просто руками развожу. Опять сочетание незнания с самоуверенностью.
Еще раз - прикладному дос программисту прерывания вообще побоку.

ТЫ САМ прямо сейчас выдумал что "должен знать"

из серии "ну я ж знал - значит ВСЕ должны знать!" - иначе чем агрессивной реакционностью это не назвать.

Татарин> Я согласен с тем, что графическая среда внесла много легко изучаемых поведенческих/управленческих паттернов, общих для программ, поэтому каждая новая прога сильно легче в начальном обучении.


Это главное. Стандартизация интерфейсов.

Татарин>>>> Вообще говоря, и не следует, и нет - любой прикладной программист под ДОС должен бы знать системные прерывания ДОС.
yacc> yacc>> Голимая чушь
Татарин>> Просто руками развожу. Опять сочетание незнания с самоуверенностью.
yacc> Еще раз - прикладному дос программисту прерывания вообще побоку.
yacc> ТЫ САМ прямо сейчас выдумал что "должен знать"
yacc> из серии "ну я ж знал - значит ВСЕ должны знать!" - иначе чем агрессивной реакционностью это не назвать.
Это у тебя просто каша в голове.

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

Использование системы - это прикладной уровень. Собссно, тут даже обсуждать нечего, 21H и есть интерфейс ДОС с прикладным программистом и он ничем не отличается от любой другой организации API. Просто вот в IBM PC было принято вот так, вызов процедуры по адресу 0000H:ff39H ничем не лучше и не хуже. Компиляторы могли оборачивать этот вызов библиотеками или не оборачивать, в любом случае система общалась с прикладным программистом вот так.

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

Татарин>> Я согласен с тем, что графическая среда внесла много легко изучаемых поведенческих/управленческих паттернов, общих для программ, поэтому каждая новая прога сильно легче в начальном обучении.
Jerard> Это главное. Стандартизация интерфейсов.
Ну да, с этим никто тут не спорит.

Но так-то говоря, никто не мешал ИБМ или МС в "Руководстве для прикладного программиста под ДОС" выдвинуть обязательные требования и рекомендации к построению ЮИ - и текстовых, и графических. С самого начала создать пользователю униформную среду и стандарты (как сделала "Эппл", МС в винде или, например "Сан" для своих СПАРК-станций).

Просто об этом не подумали, потому что и ИБМ ПК был нелюбимым ублюдком корпорации, и для ниши ПК в то время такое не было принято (кто конкуренты-то? что-то где-то около CP/M... какие уж там стандарты интерфейса).
А потом и не захотели.

Что уж там говорить, если ввод путей через табуляцию в консоли появился только уже в винде в середине 10-х (в Win7, вроде?). Треть века прошло с момента появления ДОС и консоли в ней, и всю эту треть века пользователи, неизбежно работавшие с командной строкой, отчаянно матерились, а МС делала вид, что всё правильно, всё так и нужно.
Какая там стандартизация текстовых интерфейсов, ну право же...

Татарин> Но так-то говоря, никто не мешал ИБМ или МС в "Руководстве для прикладного программиста под ДОС" выдвинуть обязательные требования и рекомендации к построению ЮИ - и текстовых, и графических. С самого начала создать пользователю униформную среду и стандарты (как сделала "Эппл", МС в винде или, например "Сан" для своих СПАРК-станций).

Там стандартизованы не только пользовательские интерфейсы. Но, и, системные. Драйверов, модулей ОС, API прикладных программ и проч.


Татарин> Просто об этом не подумали, потому что и ИБМ ПК был нелюбимым ублюдком корпорации, и для ниши ПК в то время такое не было принято. А потом и не захотели.

Так этого не было и в мейнфреймах. Никому в голову не приходило стандартизовывать API.