Компьютерный форум
Правила
Вернуться   Компьютерный форум > Форум программистов > Программирование под *nix > Общие вопросы программирования
Перезагрузить страницу Принципы оконного интерфейса
Ответ
 
Опции темы Опции просмотра
  (#31 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Post 25.11.2007, 19:40

Цитата:
Я думал, что Window придумали в Xerox, но оказалось, что это было раньше: http://en.wikipedia.org/wiki/Window_%28computing%29.
Большое спасибо!
Отличная статься, писал кто-то грамотный, все обобщено и прямо-таки подталкивает к изобретению новой терминологии.

Вот как надо придумывать термины:
Цитата:
Originally posted by Widget@Wikipedia
[b]The term was first applied to user interface elements during Project Athena in the 1980s. The word was chosen because "all other common terms were overloaded with inappropriate connotations"
Единственное - позабавила такая ненавязчивая реклама:
Цитата:
Originally posted by Widget@Wikipedia
[b]However, many programs with text user interfaces, for example Emacs, allow...
По ссылкам узнал просто редкостную уйму информации о разных ОС и их устройстве. Например, о понятиях монолитного ядра и микроядра. Если я правильно понял, получается что Windows поздних версий (XP, Vista) организована умнее Linux - это правда? Или я что-то пропустил, или там недосказано?

Еще вопрос - в статье про Intrinsics (also known as Xt, for X toolkit) изображена схема, в которой QT упоминается как надстрйка над Xlib, а wxWidjets - нет. Это упущение статьи? Или wxWidjets вообще не взывает к Xlib, а сама по себе? Или это синоним чего-то другого, например Xaw или Motif?
Ответить с цитированием
  (#32 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Arrow 25.11.2007, 19:41

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

Приведу банальный пример.
В WinAMP'е есть плагины. У любого из них есть окно настроек.
Теперь делаем порт WinAMP'а на другую ОС. Очень хорошо бы сделать так, чтобы портировать пришлось лишь сам WinAMP (оболочку), а плагины тащились следом. Ну ладно, раз формат DLL не совпадает, потребуется как минимум перекомпиляция, хотя теоретически это могло бы быть и не обязательно.
Если логически строить схему такого проекта (как бы не зная ничего о существующих технологиях программирования и API с разными ОС), то все очевидно - плагин должен создавать GUI, взывая к "оболочке", как и ко всем прочим ее функциям, а не к ОС напрямую. Он должен быть "вещью в себе". Тогда оболочка должна "протащить" сквозь себя функции ОС по созданию GUI, или в идеале просто переадресовать запрос. Типа "вам надо создать кнопку? - нет проблем! - эй, дайте сюда кнопку! - получите!".

Допустим, мы будем писать все под теми же QT или wxWidjets. GUI должен строиться как каркас вокруг каждого плагина. И что получится? Каждый компонент (оболочка + все плагины) содержит в своем составе библиотеку. Т.е. если некоторое приложение по своей сути представляет набор плагинов (как в моей рабочей задаче), то при 100 плагинах будет 101 экземпляр GUI-библиотеки. Даже если библиотека подключается динамически - она будет 101 раз подключена, что тоже не так уж и красиво.

Ну как тут без изобретения велосипедов???

P.S. большая просьба - авторство цитат сохраняйте.
Ответить с цитированием
  (#33 (permalink)) Старый
Alexey Dejneka Alexey Dejneka вне форума
Member
 
Сообщений: 451
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.11.2004
По умолчанию 25.11.2007, 20:07

Цитата:
при 100 плагинах будет 101 экземпляр GUI-библиотеки. Даже если библиотека подключается динамически - она будет 101 раз подключена, что тоже не так уж и красиво.
А что в этом плохого? Грузиться-то она будет только один раз.
Ответить с цитированием
  (#34 (permalink)) Старый
Dian Dian вне форума
Member
 
Сообщений: 5,243
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 17.09.2004
По умолчанию 26.11.2007, 06:03

Цитата:
Если я правильно понял, получается что Windows поздних версий (XP, Vista) организована умнее Linux - это правда?
В смысле микроядра, или в смысле графике в ядре?

Цитата:
А что в этом плохого? Грузиться-то она будет только один раз
Если библиотека одна и таже - то ничего. Но если продукт будет "массовым", вероятность такого расклада крайне мала - что же, всем не знающим, скажем, qt, запретить плагины писать?

Цитата:
Originally posted by 'Arachnelis @ 25.11.2007@ 18:41'
[b]Теперь делаем порт WinAMP'а на другую ОС. Очень хорошо бы сделать так, чтобы портировать пришлось лишь сам WinAMP (оболочку), а плагины тащились следом.
на мой взгляд, наиболее логичным здесь было бы самому WinAMP'у предоставить интерфейс для создания GUI настройки плагинов. Так, вроде, поступили в миранде
Ответить с цитированием
  (#35 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Post 26.11.2007, 09:53

Цитата:
В смысле микроядра, или в смысле графике в ядре?
О! Если не тяжело, расскажите и то, и другое, и попутно о чем не спросил.

Цитата:
на мой взгляд, наиболее логичным здесь было бы самому WinAMP'у предоставить интерфейс для создания GUI настройки плагинов. Так, вроде, поступили в миранде
Так, интересно! А где можно почитать о том, как это сделано в Миранде? Вроде, кажется, как-то не так давно ссылка мелькала, но уже не помню - я не знал, что они GUI передают, а мне как раз это нужно.

P.S. Я имел ввиду не мое авторство цитат, а вообще - а то следить за беседой бывает тяжело. Если уж не в полном формате (с датой, со ссылкой), то хоть просто имя.
Ответить с цитированием
Ads.
  (#36 (permalink)) Старый
Dian Dian вне форума
Member
 
Сообщений: 5,243
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 17.09.2004
По умолчанию 26.11.2007, 12:05

Цитата:
О! Если не тяжело, расскажите и то, и другое, и попутно о чем не спросил
Серьёзно - что там так плохо-то?

Цитата:
Вроде, кажется, как-то не так давно ссылка мелькала, но уже не помню - я не знал, что они GUI передают, а мне как раз это нужно
Где почитать, к сожалению, не знаю. Они вроде код свой предлагают, при большом желании можно влезть и туда.
А настройки у них да, централизованы - есть одна форма с настройками как самой миранды, так и плагинов - им отводятся отдельные странички.
Ответить с цитированием
Ads
  (#37 (permalink)) Старый
Matematic Matematic вне форума
Member
 
Аватар для Matematic
 
Сообщений: 388
Сказал(а) спасибо: 31
Поблагодарили 8 раз(а) в 8 сообщениях
Регистрация: 15.01.2007
По умолчанию 29.11.2007, 15:17

Решил поделиться своими соображениями по поводу организации взаимодействия алгоритма и интерфейса.

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

Мне так кажется, что подобная проблема, связанная с необходимостью что-то во что-то встраивать – это общая болезнь всех фон Неймановских машин. В конце концов, любая ЭВМ этого типа основана на принципе последовательного чтения и исполнения команд программы. Для того, чтобы перейти от одной части нашей “системы” к другой, нужно просто передать ей управление командой перехода. По сути дела такой подход исключает обработку программой внешних событий, происходящих в случайные моменты времени в случайном порядке, поскольку внешнее событие может произойти в то время, когда процессор машины будет сканировать не обработчик поступивших сигналов, а какую-то другую часть программы. Чтобы хоть как-то решить эту проблему еще на заре развития вычислительной техники был придуман механизм прерываний, позволяющий при возникновении запроса в принудительном порядке передавать управление в нужное место. Фактически этот механизм ставит процессор в определенных ситуациях в пассивное положение по отношению к портам компьютера. Активное состояние процессора означало бы, что он не реагирует никак на происходящие в них изменения и они никак не способны сами повлиять на его работу, что по сути дела не позволило бы организовать нормальную обратную связь, а значит и нормальное взаимодействие.

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

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

Код:
char a; int l=0;

interface()
{while(1){a=getchar(); l=1;}
}

program()
{do
if(l)
{l=0;
 putchar(a);}
while(1);
}
Что будет делать такая нехитрая программка, догадаться несложно.
По сути дела точка считывания с условием, подобным if(l) {l=0; …} в вышеприведенной программке, в этом случае будет находиться там же, где находился бы ввод в консольном варианте.

Последняя мысль. Иногда, действия пользователя могут оказаться такими, что потребуется не только изменение некоторых глобальных переменных, которые лишь впоследствии на новой итерации цикла будут прочитаны, но необходимо будет немедленно передать управление на какую-то определенную точку в основной программе (изменить в ней естественный порядок выполнения). Это может потребоваться в случае действий, требующих немедленного ответа, изменения режима работы программы, возникновения какой-то аварийной ситуации. В консольной программе этот случай не представлял бы никаких сложностей: есть оператор goto, есть вызов функции (). Но в нашем варианте реагировать приходится из интерфейсной функции переходом внутри основной. Ситуация здесь очень напоминает случай с прерываниями. Только роль запроса с внешнего устройства играет некоторое событие во внешней (интерфейсной) программе. И передавать управление предполагается не на функцию-обработчик прерываний операционной системы, а на некоторую точку или функцию основной программы. Для этой цели полезно было бы иметь некий аналог команд JMP и CALL, с той лишь разницей, что эти команды вызывались бы из одного процесса, а действовали бы на порядок выполнения команд в другом процессе. Ничего подобного в книжках по Assemblerу я правда не встречал. Интересно, в существующих системах решают ли как-нибудь данную задачу, или же предпочитают не усложнять себе жизнь подобными проблемами и находят более простые решения?

Хотел бы услышать ваше мнение по поводу всего написанного. Интересно, как все эти проблемы решаются в реальных системах.
Ответить с цитированием
  (#38 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
Wink 29.11.2007, 16:27

Цитата:
проблема ... с необходимостью что-то во что-то встраивать – это общая болезнь всех фон Неймановских машин.
+1

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

Если развить мысль и применить ее к существующей фонНеймановской архитектуре, то получается, что ядро ОС должно состоять из двух половин, функционирующих параллельно на ЦП и ГП (видеокарте). Вся GUIшная часть всех приложений висит в той половине ОС, что на видюхе, и любой сигнал от нее (реакция на действие поьзователя) порождает событие в половине ОС, висящей в ЦП, а та как угодно управляет первой.
Полностью двунаправленная схема. Только, разумеется, требуется фундаментальная доработка ГП.

Вы вдохновили меня поставить еще пару вопросов, надеюсь, кто-то подскажет ответ (несколько оффтоп, но к контексту имеет непосредственное отношение, а далеко вряд ли уйдет).
Меня интересует степень переносимости многопоточных и многомодульных приложений. Поддерживают ли микроконтроллеры, мобильники и прочие девайсы - многопоточность и динамически подключаемые библиотеки?
Ответить с цитированием
  (#39 (permalink)) Старый
Rius Rius вне форума
Программист
 
Аватар для Rius
 
Сообщений: 7,394
Сказал(а) спасибо: 22
Поблагодарили 936 раз(а) в 920 сообщениях
Регистрация: 27.08.2004
Адрес: Russian Federation
По умолчанию 29.11.2007, 17:10

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

Цитата:
Собственно, я примерно на это и намекал изначально - хорошо бы иметь возможность просто назначить для события интерфейса вызов функции логики
можно по событию интерфейса запустить отдельный поток или просто асинхронное выполнение какой-либо нужной функции.
Ответить с цитированием
  (#40 (permalink)) Старый
Dian Dian вне форума
Member
 
Сообщений: 5,243
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 17.09.2004
По умолчанию 29.11.2007, 17:19

Цитата:
это общая болезнь всех фон Неймановских машин
И, надо пологать, любой архитектуры с последовательным выполнением команд?
А как быть с SMP? Или оно перестаёт быть фон Неймановским в силу, скажем, синергизма?
Цитата:
Возникает вопрос, как организовать влияние интерфейсного процесса на основной. И тут я хотел со своей не совсем профессиональной стороны предложить такое решение. Достаточно организовать группу переменных (область памяти), которая будет доступна как первой, так и второй подпрограмме.
Собстенно, и возможны-то только общий доступ к памяти, либо передача сообщений через что-то, что имеет общий доступ к памяти обоих приложений. Так что ничего антипрофессионального

Цитата:
...в случае действий, требующих немедленного ответа, изменения режима работы программы... В консольной программе этот случай не представлял бы никаких сложностей: есть оператор goto, есть вызов функции ().
На самом деле здесь всё столь же просто - там, где в консольной программе было обращение к действиям пользователя, положено обращение к общей памяти (т.е. когда "вычислительный" поток занят, в консольном варианте он не смог бы отреагировать на действие пользователя). Задержка между вводом и реакцией абсолютно такая же. Однако, мы можем организовать флаг во внутренних циклах "вычислительного" потока, говорящий ему о том, что работу можно закончить досрочно, а в GUI потоке выставлять его - в этом случае время реакции системы может очень заметно сократися.

Цитата:
Меня интересует степень переносимости многозадачных и многомодульных приложений. Поддерживают ли микроконтроллеры, мобильники и прочие девайсы то и другое?
Многозадачность обеспечивается ядром ОС, а динамическая компоновка - её же загрузчиком. Что бы поддерживать "многомодульность" платформа должна допускать загрузку кода, а для поддержки многозадачности необходим таймер, вызывающий прерывания (это простейший девайс, он есть практически везде). Таким образом, ничего сверхъестественного от аппаратной платформы не требуется
P.S. Современный мобильник - жуткий агрегат, делают их на основе настоящих процессоров, а прошивки не всегда укладываются в 128Mb
Ответить с цитированием
  (#41 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
По умолчанию 29.11.2007, 19:35

Большое спасибо!

Цитата:
А как быть с SMP? Или оно перестаёт быть фон Неймановским в силу, скажем, синергизма?
Попытки поиска по словам "SMP" и "синергизм" ни к чему не привели.
Ссылочку на информацию по-конкретнее не дадите? Интересно.
Ответить с цитированием
  (#42 (permalink)) Старый
Alexey Dejneka Alexey Dejneka вне форума
Member
 
Сообщений: 451
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.11.2004
По умолчанию 29.11.2007, 23:45

Цитата:
Последняя мысль. Иногда, действия пользователя могут оказаться такими, что потребуется не только изменение некоторых глобальных переменных, которые лишь впоследствии на новой итерации цикла будут прочитаны, но необходимо будет немедленно передать управление на какую-то определенную точку в основной программе (изменить в ней естественный порядок выполнения). Это может потребоваться в случае действий, требующих немедленного ответа, изменения режима работы программы, возникновения какой-то аварийной ситуации. В консольной программе этот случай не представлял бы никаких сложностей: есть оператор goto, есть вызов функции (). Но в нашем варианте реагировать приходится из интерфейсной функции переходом внутри основной. Ситуация здесь очень напоминает случай с прерываниями. Только роль запроса с внешнего устройства играет некоторое событие во внешней (интерфейсной) программе. И передавать управление предполагается не на функцию-обработчик прерываний операционной системы, а на некоторую точку или функцию основной программы. Для этой цели полезно было бы иметь некий аналог команд JMP и CALL, с той лишь разницей, что эти команды вызывались бы из одного процесса, а действовали бы на порядок выполнения команд в другом процессе.
В Unix есть функция kill, передающая "сигнал" от одного процесса другому (программный аналог аппаратных прерываний), функция sigaction, устанавливающая обработчик сигнала, функции setjmp/longjump, предназначенные для нелокальной передачи управления из одной функции в другую. Правда, если программа использует какие-либо структуры данных (например, вызывает malloc/new), то заставить ее надежно работать с такими средствами может оказаться весьма проблематичным.
Ответить с цитированием
  (#43 (permalink)) Старый
Dian Dian вне форума
Member
 
Сообщений: 5,243
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 17.09.2004
По умолчанию 30.11.2007, 05:15

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

"синергизм" - грубо говоря, разница между целым и суммой его частей
Ответить с цитированием
  (#44 (permalink)) Старый
Matematic Matematic вне форума
Member
 
Аватар для Matematic
 
Сообщений: 388
Сказал(а) спасибо: 31
Поблагодарили 8 раз(а) в 8 сообщениях
Регистрация: 15.01.2007
По умолчанию 30.11.2007, 07:40

Попросил бы кого-нибудь из уважаемых участников форума переписать мою программку, код которой я приводил выше, нормальным способом, по-настоящему. Интересно, как она будет реально выглядеть, написанная под UNIX - Linux.
Предлагается внести следующее изменение в работу основной функции
Код:
if(l)
{l=0;
if(a=Esc) break;
putchar(a);}

#define Esc <номер символа, приходящего с клавиатуры при нажатии клавиши Esc>
Предполагается также интерфейсный процесс запускать из основного как дочерний. Насколько я понимаю, выход из основного процесса в таком случае завершит без явных действий в программе и дочерний.
Данная программулина будет считывать символ, приходящий с клавиатуры, и выдавать его на экран. При нажатии на Esc программа будет завершаться. Отличительная ее особенность, по сравнению с обычным вариантом с одним процессом, в том, что процессор неоправданно будет использовать свое время (пустые вычисления в цикле) и разогреваться. Но ведь это игрушка. Наверное, можно решить и эту проблему как-то: поставить цикл в ожидание, пока ни произойдет считывание символа в цикле интерфейсной функции. Интересно, как это сделать?
Жду кодов!

По поводу фон Неймановских машин и многопроцессорности. Думаю, случай с многопроцессорной системой принципиально ситуацию не меняет. Если только один процессор может вызвать прерывание в каком-либо другом, это как-то обеспечивает прямую и обратную связь между ними. Фактически я что-то подобное и имел в виду, только для случая многозадачности с одним процессором. На самом деле многозадачность с прерываниями и переходами от таймера это и есть моделирование такой многопроцессорной системы, ее реализация на одном процессоре. Так что SMP тут Америку не открывает и врятли может принципиально изменить ситуацию с фон Неймановскими (алгоритмическими) машинами. Более подробно свои соображения по этому поводу я напишу в другой раз.
P.S. Я здесь не претендую на глубокую научность и истину в последней инстанции. Все это лишь мои соображения, но, думаю, доля смысла в них есть.
Ответить с цитированием
  (#45 (permalink)) Старый
Arachnelis Arachnelis вне форума
Member
 
Сообщений: 1,324
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 02.07.2007
По умолчанию 30.11.2007, 14:14

Присоединяюсь к ожиданию уважаемого Matematic'а.

Цитата:
Что бы поддерживать "многомодульность" платформа должна допускать загрузку кода, а для поддержки многозадачности необходим таймер, вызывающий прерывания (это простейший девайс, он есть практически везде). Таким образом, ничего сверхъестественного от аппаратной платформы не требуется
P.S. Современный мобильник - жуткий агрегат, делают их на основе настоящих процессоров, а прошивки не всегда укладываются в 128Mb
Хочу уточнить, как обстоят дела на практике.
Допустим, некий код на Си/Си++ под WinAPI-интерфейс без XP-наворотов. Запустится ли в общем случае такая прога на WinCE (или как там она)? Потребуется ли перекомпиляция? Если да, то есть ли соответствующие компиляторы Си++, или допустим лишь чистый Си? Возвращаясь к первоначальному вопросу - возможно ли создание многопоточных приложений?

Есть ли Linux для смартфонов? Если да, то каковы ответы на эти вопросы для нее?

P.S. Кстати, еще один малость оффтопный вопрос - услышал, что Windows и Linux написаны на чистом Си, а не на С++ - это правда?
Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Вкл.
Pingbacks are Вкл.
Refbacks are Выкл.


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Некоторые принципы по написанию программ, для новичков dect Общие вопросы создания ПО 15 24.09.2011 19:18
Общие принципы организации синтаксического разбора в С++ 45182 Вопросы начинающих программистов 2 09.01.2011 18:41
Программа демонстрирующая принципы ООП (полиморфизм, инкапсуляцию, наследование) TidalAeon Вопросы начинающих программистов 0 11.12.2010 16:32
Принципы управления DVD и CD приводами tumanovalex Железо. Написание драйверов 0 29.08.2008 00:21
Принципы решения написания программы Frullani Lisp 2 27.09.2007 19:23
Принципы форматирования файлов shatush Общетематический 3 29.06.2007 23:16
Создание оконного приложения для Windows с 98 на VS2005 Antsu Visual C++ 5 17.01.2007 10:34
Объясните общие принципы работы CAsyncSocket Palmman Сетевое программирование 2 02.10.2006 20:28
Принципы создания средствами VC++ 6.0 интерфейса типа "проводник" Postum Visual C++ 8 26.01.2005 18:10
Принципы написания трояна Anonymous Delphi 30 19.03.2004 16:37
Принципы DoS-атак как их создавать Felix Delphi 2 11.01.2004 06:27
Принципы работы менеджера виртуальных экранов lv Visual C++ 0 01.11.2003 05:24



Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Нardforum.ru - компьютерный форум и программирование, форум программистов