|
|
|
| Я си только начинаю учить и кроме буилдера (сейчас изучаю) и визуал студии ничего не знаю... Собствено вопрос в названии темы... | |
|
|
|
|
|
|
|
для: Krasnodar
(25.01.2007 в 01:39)
| | Есть программа, написанная на C - операционная система Windows, которая вынуждена запускать другие программы и выполнять часть их работы (отрисовывать кнопки, окошки и т.п.) - Windows API это библиотека, которая позволяет писать программы для Windows. Все библиотеки для создания Windows-программ (MFC в VC++ или VCL в С++ Builder) используются Windows API, т.е. служат обёрткой для этой библиотеки. Windows API можно грубо назвать интерфейсом, через который программы общаются с операционной системой. Например, имеется база данных MySQL - чтобы писать программы, взаимодействующие с ней нужно использовать MySQL API - библиотеку и набор функций перечисленных в заголовочном файле mysql.h. Вот здесь тоже самое, только взаимодействуете вы с операционной системой. | |
|
|
|
|
|
|
|
для: cheops
(25.01.2007 в 01:55)
| | Если я вас правильно понял, это стандартная библиотека для этих програм (буилдер, визуал студия и д.р.)? | |
|
|
|
|
|
|
|
для: Krasnodar
(25.01.2007 в 02:05)
| | А если писать прогу с интерфейсом но так чтоб она работала под FreeBsd , Linux ,.. тоже придется использовать библеотеку интерфейсов от этих систем? | |
|
|
|
|
|
|
|
для: sidPR
(25.01.2007 в 10:25)
| | Windows API - это по сути аналог системных вызовов Linux или FreeBSD, только у NIX* системные вызовы не связаны с графикой (операционные системы не обладают графическими ядрами). В UNIX-подобных операционных системах для графики испольльзуется Window X сервер и программы просто обращаются к нему с запросами (как допустим к серверу базы данных): вот тут нарисуй мне то-то. | |
|
|
|
|
|
|
|
для: Krasnodar
(25.01.2007 в 02:05)
| | Это набор бибилиотек и стандартом они являются не для сред разработки, а для операционной системы Windows в целом. Изначально только на Windows API можно было разрабатывать программы для Windows - потом разработали облегчающие библиотеки VCL в Builder и MFC в Visual Studio. Для этих сред их собственные библиотеки являются стандартными, а API - это то, при помощи чего были разработаны эти библиотеки и при помощи чего любая программа взаимодействует с операционной системой.
Грубо говоря читаете вы файл при помощи функции fread(), на самом деле под Windows идёт обращение к функции Windows API - ReadFile() - если вы обратитесь к этой функции напрямую, вы прочитаете файл быстрее, однако программу уже нигде кроме Windows откомпилировать не сможете. Тоже самое под UNIX - обращаетесь к fread(), а на самом деле вызывается системный вызов read() (кстати, именно поэтому файловые функции в C++ начинаются с f - чтобы не совпадали с системными вызовами UNIX). Вы можете использовать системный вызвов UNIX в программе, но уже под Windows такую программу не откомпилируете. Используя fread() вы откомпилируете программу где угодно, хоть под Macintosh, хоть под QNX и вообще везде, где имеется C-компилятор.
Вот именно поэтому появилась стандартная библиотека - функции этой библиотеки известны под любой операционной системой и не зависят от API. Для процессоров используется Ассемблер, который зависит от архитектуры процессора и уникален для каждого процессора, языки программирования уже не зависят от процессора, но компиляторы пишутся с использованием ассемблера для каждого из процессоров. Вот API - это по сути своеобразный ассемблер для операционной системы. API - учитывает архитектуру, стандартная библиотека, язык программирования - нет. | |
|
|
|
|
|
|
|
для: cheops
(25.01.2007 в 14:06)
| | В одной из тем ниже был вопрос такого плана - "Картинки надо будет делать в API?" (не дословно)... Как это понять и как сделать? | |
|
|
|
|
|
|
|
для: Krasnodar
(25.01.2007 в 14:20)
| | Вы можете взять изображение и вывести его в любую точку окна при помощи Windows API, а можете взять элемент управления TImage из библиотеки VCL и загрузить изображение в него - оно будет выводиться там где будет расположен элемент, вы можете передвигать сам элемент (с картинкой), но вообще не вовсе области окна (а вызывать функции API будет библиотека VCL), только если не используете пустое окно... кстати, это мысль, можно вообще говоря и без API обойтись прорисовывая всё при помощи таких элементов... на манер как делают окна-заставки. | |
|
|
|
|
|
|
|
для: cheops
(25.01.2007 в 15:39)
| | Получается что в большенстве случаев можно обоитись и без API? Тогда может и голову пока на этом не заморачивать? | |
|
|
|
|
|
|
|
для: Krasnodar
(25.01.2007 в 15:51)
| | Да, в большинстве случаев можно обойтись без API, обычно им голову заморачивают на 2-3 году обучения С++ (а иногда вообще не изучают, компенсируя глубокими знаниями библиотек VCL и MFC). API, обработка событий требуются в уникальных случаях, которые возникают не часто и не у всех разработчиков. Например, захотите вы иконку в системный трей поместить - стандартных средств нет, компонент возможно какой и имеется, но за деньги - берёте и сами её туда помещаете, прибегая к Windows API - и всё в таком же духе - не нравится, как в VCL или MFC сделано, не можете найти библиотеку или компонент - делаете сами как вам нравится (разумеется это требует усилий - деньги за библиотеки не просто так требуют :).
VCL, MFC - это по сути движки, шаблоны (дизайна имеется в виду, а не C++) и FrameWork в одном флаконе, а API - это то, на чём разрабатывают движки. Вы можете использовать для построения сайта движок Nuke, созданный на PHP, а можете взять PHP и разработать свой движок, который будет выполнять то, что вам нужно, а не разработчикам Nuke. Тоже самое и с API, только здесь всё гибче и инструментов для перехода к API на уровне VCL и MFC - больше - вы можете разрабатывать библиотеку на VCL и MFC, делая API-вставки более естественно, чем PHP-вставки на Nuke. Т.е. с выходом новых версий библиотек ваша работа не пропадёт. Ну и разумеется зная API Windows вы будете очень хорошо поинимать библиотеки VCL и MFC, да и сам Windows. Изучить его стоит, но не сразу, сначала требуется приобрести глубокие знания в области C и C++, стандартной библиотеки, иначе сложно будет работать. | |
|
|
|