Win32 приложения

[zubr]

чего бы взять для примера...
DrWeb, QIP, uTorrent, UltraISO, Notepad++
это наверное все вирусы)
или я где то ошибся?

А конкретнее, откуда инфа?

[Алексей++]

тогда я не понял

нууу, тогда я тоже

[Ochkarik]

чего бы взять для примера...
DrWeb, QIP, uTorrent, UltraISO, Notepad++
это наверное все вирусы)
или я где то ошибся?

А конкретнее, откуда инфа?

честно говоря от балды привел... исключительно чтоб ваши слова не столь одиозно звучали.

ну например  Notepad-wiki

Notepad++ — свободный текстовый редактор для Windows с подсветкой синтаксиса большого количества языков программирования и разметки. Он базируется на компоненте Scintilla

Scintilla — компонент редактирования с открытым исходным кодом для Microsoft Windows, и Linux с GTK+...
На Linux использует библиотеку GTK+, на Windows — Windows API.

uTorrent - разработка началась в 2005году, однако
"Versions of µTorrent up to 1.8.5 build 17091[21] can use as little as 14 MB of RAM running on a 486 processor on Windows 95."
однако для MacOS - только с 2010, для Linux с 2010го. соответственно - только подозрения что ничего кросплатформенного не использовалось... и работа началась с винды. и размер, сейчас не помню, но что то около двух сотен кб.
MFC библиотеки вроде не линкуются. да и разработчик тоже...хакер еще тот)

UltraISO  занимает порядка 1мбайта.
"Windows 7/2008/Vista/2003/XP (32bit and 64bit), Windows 2000, ME, 98SE, 98, or Windows NT4.0 SP6a+ operating system ."
Intel Pentium 166MHz or above.
интересно, кто граф-библиотек до сих пор поддерживает "Windows NT4.0 SP6a+"?)))
хотя тут тоже пальцем в небо. если честно)

про DrWeb, на недельке уточню, самому интересно)

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

[Finch]

Ochkarik, Если используется WinAPI, то не о какой кроссплатформенности речи не идет. .NET изначально позиционировали как кроссплатформенное решение. Полная поддержка есть только для Windows. Стараниями фирмы Novell есть попытка .NET перевести на *nix. Но фирму Novell уже продали. И насколько я слышал, купил ее фонд довольно близкий M$. Так что, дальнейшая судьба проекта mono не известна. Да и на моей памяти сушествует всего 3 проэкта написанных на mono.

[zubr]

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

[Ochkarik]

Finch, да я ни одного слова не сказал о NET) это просто были размышления что есть некоторые программы по недоразумению написанные без....

zubr,
ага. и QT для Windows, наверное тоже не использует API, либо ее те самые извращенцы пишут) оно наверное как-то так работает... само собой) интересно для чего библиотека QtGui.dll обращается к библиотеке GDI32.dll? случайно наверное)
это не спор.... я просто хочу сказать что хоть кто то, но должен помнить о том что есть такое слово API)

[zubr]

zubr,
ага. и QT для Windows, наверное тоже не использует API, либо ее те самые извращенцы пишут) оно наверное как-то так работает... само собой) интересно для чего библиотека QtGui.dll обращается к библиотеке GDI32.dll? случайно наверное)
это не спор.... я просто хочу сказать что хоть кто то, но должен помнить о том что есть такое слово API)

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

[RXL]

QT, конечно, использует Win32 API в винде. Но QT является кроссплатформенной библиотекой и точно также использует другие API, характерные для используемой платформы. Главное, что это полноценный классовый фреймворк, дающий обширный сервис через свое API.

[Ochkarik]

да ладно.. я то чего полез) я и читать не умею)

[Алексей++]

Ochkarik, так в винде то конечно использует, как же не использовать, приложение ведь запущено в винде )). Ну так и IDE виндового варианта используется

 в Qt виндовое окно и диалог, но вот содержимое их - чисто отрисованное, спаем не палится ничего

[Dimka]

в Qt виндовое окно и диалог, но вот содержимое их - чисто отрисованное, спаем не палится ничего

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

[Алексей++]

Dimka, так в Qt и философия окон (виджетов) совсем другая

Насчёт кнопок: в винде кнопки/окна ввода/и прочие элементы управления, созданные из ресурса, - не есть постоянно отдельное окно , в отличие от созданных через Create собственноручно. Они там временные (как это разграничено - я не знаю, наверное имеется некий пул хендлов, если окно неактивно, хендлы его контролов могут быть захапаны другими окнами). Поэтому доступ к хендлу контрола осуществляется через GetDlgItem(hParent,ID) . Если же пытаться сохранить хендлы контролов в мап, к примеру , то всё это проработает некоторое время, а потом рухнет )))

в Qt же всегда - один хендл на один диалог. Ну ко всем остальным виджетам - доступ только по указателю

[Ochkarik]

Поэтому доступ к хендлу контрола осуществляется через GetDlgItem(hParent,ID) .

по моему это не совсем так. это верно только для диалогов - там обращение к контролам может происходить по его ID (а может и не происходить).
для контролов, рожденных на классе основного окна(на родительском окне) - хендл выдается при рождении и дальнейшее обращение к контролу происходит через него. при стандартном пути создания окна (как это было изначально предусмотрено) все контролы могут размещатся во время WM_CREATE (да и в любое другое время тоже кстати. хоть динамически), путем вызова:
   //поле вводда разрядности квантования
   hwndEdit_ =      CreateWindowEx();
дальнейшие манипуляции с контролом происходят через его хендл:
   SendMessage(hwndEdit_,WM_SETFONT,fnt_avf,0);

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

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

[Алексей++]

>>по моему это не совсем так.
так я и говорю, что хендлы мечутся только у контролов, созданных из ресурса. Прочитай повнимательнее мой пост;)

ну а Qt не делает то же самое. Хотя, я их и не сравнивал - лучше или хуже. Просто иначе

[Dimka]

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

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

Т.е. окно как концепция - неудачная основа иерархии сущностей. Впрочем, поскольку в WinAPI ООП в зачаточном состоянии - тяжёлое наследние 1985 года, окно как основа понятно. Но морально устарело

[Ochkarik]

>>по моему это не совсем так.
так я и говорю, что хендлы мечутся только у контролов, созданных из ресурса. Прочитай повнимательнее мой пост;)

ну а Qt не делает то же самое. Хотя, я их и не сравнивал - лучше или хуже. Просто иначе

я имел в виду что любой контрол в винде создается одинаково) в конечном счете через CreateWindowEx, просто в диалоге это делает встроенный скрипт. про "мечутся" я не понял наверное) про QT - это Дмитрию)

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

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

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

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

[zubr]

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

Это смотря для каких целей. К примеру для подобной программы:

вполне.

[Ochkarik]

эммм) красиво) еще какой нибудь стрелочный индикатор рядом напрашивается) даже странно что их перестали применять... вот была ВЕЩЬ!

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

вот жешь, а такое я в живую даже не представлял что делали...

[zubr]

Да, таймер, мышкой берешь за ползунок и крутишь. Я этот проект полгода назад делал.

[Sla]

zubr, а кто рисовал?

[zubr]

Заказчик предоставил скрины.