Языки программирования, Опрос, обсуждение Опции

[dark-ila]

C/C++ и спорить даже неочем!

[proton]

+1
А как насчет C# ?

[dark-ila]

Забыл впихнуть его в мой список....
тогда:

C/C++/C# и спорить даже неочем!

[proton]

Забыл впихнуть его в мой список....
тогда:

не совсем так...
C++ и C# - немного разные языки, но они оба основаны на C

[dark-ila]

=> C рулит!

[aler]

Паскаль - для user-программ
Ассемблер - для системных
может еще Java (для UNIX/Linux)

[drusha]

В АссемБЛЕре я разочаровался. Он абсолютно непереносим. Скоро 32-разрядная архитектура и вовсе сдохнет, тогда ассемблер другой понадобится. "С" более переносим, даже на другие процессоры, а системные проги (даже драйверы) можно писать на нём (я писал VXD под Win-95/98 на С, но не ++, надо только слинковать с маленьким модулем, написанном на Ассемблере). Если привые к С/С++, то можно всё что угодно. Раньше я писал на Паскале. Паскаль более дубовый язык, но и на нём многое можно. Например, имхо, Borlsnd C++ Builder очень портит дельфёвая реализация VCL.

Напрягает разнообразие языков. Когда приходится одну прогу (но разные её модули) писать на C--/С++, Паскале (Дельфи), Бейсике (VBA), SQL и Ассемблере... Ну, нафига, спрашивается?... Я думаю, что будущее за С-подобными языками, к которым я отношу и джаву. Ну, сама джава - это больше для апплетов и серверлетов...

Yj lkz leib - dc` hfdyj - LISP? b njkmrj LISP!!!

[Frut]

LISP)) это же вроде бы алгоритмический язык?

[drusha]

Ну, да! Конечно.

Когда-то я писал на AutoLISP под AutoCAD. Если кому-нибудь интересно, могу дать свою программу, которая реализована на AutoLISP, и она в среде AutoCAD реализует моделирование оптических систем. Можно расчитывать оптические системы любой сложности. Но больше она ориентирована на любительское телескопостроение.

Могу также поделиться вирусом, который я написал на АвтоЛИСПе

Ещё я когда-то написал собственный интерпретатор языка LISP, который называется TopoLISP. Там поддерживается управление топологией списков. И что интересно, хоть Лисп означально не имеет поддержки объектно-ориентированной парадигмы, но достаточно было написать небольшой модуль на самом Лиспе, как среда этого языка стала объектно-ориентированной!

На Лиспе хорошо писать системы искусственного интеллекта.

А ещё Лисп обладает удивительными свойствами. Например, можно написать интерпретатор Лиспа на самом Лиспе. Легко на нём пишутся автоаппликативные и авторепликативные программы, а так же программы с самомодифицирующимся кодом. Короче, Лисп - это идеальная среда для вирусов, червяков и прочей виртуальной живности. Да к тому же, с искусственным интеллектом!

[aler]

В АссемБЛЕре я разочаровался. Он абсолютно непереносим. Скоро 32-разрядная архитектура и вовсе сдохнет, тогда ассемблер другой понадобится. "С" более переносим, даже на другие процессоры, а системные проги (даже драйверы) можно писать на нём (я писал VXD под Win-95/98 на С, но не ++, надо только слинковать с маленьким модулем, написанном на Ассемблере). Если привые к С/С++, то можно всё что угодно. Раньше я писал на Паскале. Паскаль более дубовый язык, но и на нём многое можно. Например, имхо, Borlsnd C++ Builder очень портит дельфёвая реализация VCL.

Напрягает разнообразие языков. Когда приходится одну прогу (но разные её модули) писать на C--/С++, Паскале (Дельфи), Бейсике (VBA), SQL и Ассемблере... Ну, нафига, спрашивается?... Я думаю, что будущее за С-подобными языками, к которым я отношу и джаву. Ну, сама джава - это больше для апплетов и серверлетов...

Yj lkz leib - dc` hfdyj - LISP? b njkmrj LISP!!!

C,C++,Java - нечитабельны (даже простую программу в исходных кодах долго придется разбирать)
"Паскаль более дубовый язык, но и на нём многое можно" - не многое а все что угодно, как и на любом современном языке программирования, разница только в сложности реализации.
"В Ассемблере я разочаровался. Он абсолютно непереносим." - переносимость нужна тем, кому лень писать программу для каждой платформы

[drusha]

Лично мне - лень под каждую платформу. Тем более, которой пока ещё нет. А хочется чего-то вечного, чтоб сразу на века... Ну, как наши предки делали. Самолёты Ил-14, Ил-18 до сих пор кое-где летают... Ракета Р-7 (это первые две ступени, которые вывели первый Спутник, а в зависимости от третьей ступени она называлась "Восток", "Союз", "Молния"...) тоже летает до сих пор... Вот, хотелось бы чтобы и программы такими же были... Но, вот, что есть насчёт даты-времени в стандартной библиотеке (stdlib) ANSI-стандарта языка C (из С++/С# её функции также доступны), всё это будет правильно работать где-то до 2038 года. То есть, грядёт "проблема 2038 года", и тогда многие программы, написанные на С/С++, единомоментно сдохнут. Это касается 16- и 32-разрядных платформ Windows (подозреваю, что и под UNIX тоже, и даже MAC OS). Возможно, в 64-разрядных версиях эта проблема уже не стоит. Проживёт ли архитектура 16/32 разряда ещё 30 лет - я не знаю. Но многие предметы 30-летней давности (не только самолёты и ракеты, но иавтомобили, мотоциклы, холодильники, велосипеды, фотоаппараты, телевизоры, радиоприёмники, катушечные магнитовоны и проигрыватели виниловых дисков) не только работают, но и во многом превосходят современные аналоги.


Насчёт ассемблера.
Кстати, есть (не очень, правда, распространены) лисп-машины, пролог-машины... Там такие языки как Лисп (конкретно, Зета-лисп), Пролог и т.п. поддерживаются на аппаратном уровне: по сути они являются для них ассемблерами.

[OXOTHuK-SM]

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


На счёт языков я не знаю не один кроме языка для написания web странниц и то плохо знаю

[aler]

Я думаю если СССР прожил на десяток лет больше то наши программисты точно написали бы супер программы на века думаю что были бы у нас самые лучшее вирусы и трояны для взлома американских компов в белом доме
На счёт языков я не знаю не один кроме языка для написания web странниц и то плохо знаю

Первый вирус использующий защищенный режим(и при этом совместимый с Windows) для укрывательства от DOS-антивирусов (давно было, тогда еще было очень много DOS-программ) - российский:

PM.Wanderer
Неопасный резидентный полиморфный вирус, использующий защищенный
(виртуальный) режим процессоров i80386-Pentium. Для установки своей
резидентной копии в память и переключения в защищенный режим процессора
(Protected Mode) использует документированный интерфейс VCPI (Virtual
Control Programm Interface) драйвера расширенной памяти EMS (EMM386).
Вирус заражает COM и EXE-файлы при их запуске или открытии (f.4b00h,
f.3dh Int 21h). При старте инфицированной программы, вирусный
полиморфный декриптор расшифровывает основное тело вируса и передает
ему управление. Далее основной вирусный код выделяет участок памяти в
верхних адресах, копирует в него собственный код и передает ему
управление. Затем он восстанавливает код инфицированного файла в
программном сегменте (для EXE-файлов также производит настройку адресов
перемещаемых элементов) и приступает к непосредственному внедрению
в память своей резидентной копии. Первым делом вирус пытается выяснить
установлен ли в системе драйвер EMS. Для этого он получает адрес
прерывания INT 67h и проверяет наличие строки EM* в заголовке драйвера.
Далее вирус проверяет не находится ли уже в памяти его резидентная
копия - вызывает функцию AX=0BABAh INT 21h и проверяет ответ AX=0FA00h.
Если драйвер EMS не установлен в системе или вирусная резидентная копия
уже находится в памяти, а также в дальнейшем -при отсутствии интерфейса
VCPI, вирус освобождает ранее выделенную память и отдает управление
программе-вирусоносителю, заканчивая тем самым свою "жизнедеятельность"
в системе. Если же "условия флоры" благоприятствуют, то вирус
"перехватывает" INT 01 и трассирует INT 21h с целью нахождения
определенной последовательности байт, присутствующих в оригинальном
обработчике INT 21h MS - DOS версий 5.00 - 7.00. Если данная
последовательность обнаружена, то вирус запоминает адрес ядра
обработчика INT 21h, обычно расположенного в области HMA. В дальнейшем
вирус будет использовать этот адрес для вызова INT 21h при заражении
файлов. Дальнейшие действия вируса - проверка наличия в системе
интерфейса VCPI и получение 4-ех адресов страниц памяти. Затем вирус
получает адрес интерфейса VCPI, таблицу страниц и адрес глобальной
дескрипторной таблицы GDT (Global Descriptor Table), состоящей из трех
элементов (первый - дескриптор сегмента кода, два другие - используются
драйвером VCPI). Вирус записывает в таблицу страниц ссылку на страницы,
выделенные им драйвером VCPI, получает физический адрес страницы памяти
сегмента, в котором вирус в данный момент находится. Потом получает
регистры глобальной дескрипторной таблицы GDT и дескрипторной таблицы
прерываний IDT (Interrupt Descriptor Table). Далее вирус создает три
собственных дескриптора (кода и данных) и дескриптор сегментов
состояния задачи TSS (Task State Segment) в глобальной дескрипторной
таблице GDT, подготавливает значения для регистров CR3, GDTR,IDTR,LDTR,
TR и адрес CS:EIP точки входа в защищенный режим и производит
переключение процессора в защищенный режим работы с наивысшим уровнем
привилегий - 0. В защищенном режиме вирус корректирует таблицу GDT,
создавая в ней два собственных дескриптора сегментов и производит поиск
дескриптора TSS. После чего вирус устанавливает две аппаратные
контрольные точки по командам (Breakpoints) на первый байт кода
обработчика INT 21h (адрес 0000:0084h) и на первый байт кода в BIOS по
адресу 0FE00:005Bh (линейный адрес 0FE05Bh). Обычно в BIOS по адресу
0FE00:005Bh находится команда перехода (Near Jump) на процедуру
перезапуска компьютера. Затем вирус корректирует дескрипторную таблицу
прерываний таким образом, чтобы установить на прерывания: 1 (особый
случай отладки) и 9 (клавиатура) собственные дескрипторы обработчиков
данных прерываний. После этих приготовлений вирус копирует свой код
в страницу памяти, полученную им еще до входа в защищенный режим и
производит переключение процессора в виртуальный режим работы.
Вирусный обработчик INT 09 производит контроль за наличием и (или)
восстановлением своих двух контрольных аппаратных точек. А также,
данный обработчик отслеживает нажатие на Ctrl-Alt-Del и в этом случае
"сбрасывает" все аппаратные контрольные точки. Вирусный обработчик
особого случая отладки проверяет произошло ли нарушение одной из двух
"вирусных" контрольных точек по адресу команды.Если управление в данный
обработчик попало из точки, находящейся "на процедуре" в BIOS -
перезагрузки компьютера, то вирус сбрасывает все аппаратные контрольные
точки, так же, как и обработчик INT 09 при нажатии на Ctrl-Alt-Del.
Если же нарушение вызвано контрольной точкой оригинального обработчика
INT 21h, то вирус анализирует значение регистра AX (или AH) с целью
определения функции прерывания INT 21h и в зависимости от этого
предпринимает различные действия. Если AX=0BABAh, то вирус считает, что
данный вызов исходит от его "собрата",записывает в AX значение 0FACCh и
возвращает управление оригинальному обработчику INT 21h. Если AX=3506h
(получить адрес прерывания INT 06;обычно такой вызов существует во всех
программах, написанных на языках высокого уровня: C, Pascal,...), то
вирус пытается найти в пространстве линейных адресов 0-90000h некоторую
последовательность байт, очевидно, принадлежащих программе ADinf
(Дмитрию Мостовому - автору ADinf, не удалось найти такую версию ADinf
от 10.00 до 11.01, в которой данная последовательность байт бы
присутствовала). Если данная последовательность будет вирусом найдена,
то он неким образом модифицирует найденный код, так, чтобы управление
не попадало на вызов какой-то межсегментной процедуры. Если AX=4B00h
(запуск программы) или AH=3dh и AL не равно ?Fh (открытие файла только
на чтение), то вирус копирует свой код по адресу 9000:0000h (линейный
адрес 90000h),переключает процессор в виртуальный режим работы и отдает
управление своему коду, находящемуся в пределах первого мегабайта в
сегменте 9000h. Вирус проверяет последние две буквы расширения имени
файла и производит создание своей полиморфной копии и заражение файлов
размером более 4K. Причем вирус внедряет свой код в начало COM или в
середину (сразу же за заголовком) EXE-файлов, запоминая оригинальный
программный код в конце файлов."Реальный рабочий код" вируса составляет
3684 байт, но на практике инфицированные файлы имеют приращение длины
более 3940 байт.При возникновении любой ошибки в процессе заражения или
при выходе из виртуального режима процессора вирус вызывает INT 21h с
AX=4B00h для вызова особого случая исключения и возвращения управления
оригинальному обработчику INT 21h. Вирус в своем теле содержит текст
"WANDERER,© P. Demenuk". По этой строке, видимо,можно сделать выводы,
что автором данного "шедевра" следует считать московского человека -
Петра Деменюка. Через три года Петя создал все-таки свой новый
"великолепный продукт, достойный восхищения...".
Из всего вышесказанного следует, что обнаружить резидентную копию
данного вируса, находящегося в нулевом кольце защищенного режима
процессора обычными способами невозможно. Для обнаружения вируса в
памяти необходимо переключаться в защищенный режим с наивысшими
привилегиями и по таблицам GDT или IDT производить его поиск. Но
попытаться обнаружить признаки вируса в системе можно и обычными
способами. Для этого необходимо прочитать линейные адреса двух первых
аппаратных контрольных точек (0 и 1) и сравнить их со значениями,
которые описаны выше. На основании наличия определенных адресов и
делается вывод о возможности нахождения вируса PM.Wanderer в памяти
компьютера.
Теперь немного о результатах тестирования. При заражении нескольких
тысяч файлов-жертв вирус проявил себя, как "жилец" - все зараженные
файлы оказались работоспособными. Здесь надо только сделать поправку -
файлы могут оказаться неработоспособными в том случае, если их стек
после заражения окажется в области вирусного кода. PM.Wanderer при
заражении файлов не корректирует значения стартовых SS:SP. Как уже
отмечалось выше, вирус сохраняет способность к воспроизводству,только в
том случае, если в системе установлен драйвер EMS (EMM386). При
установленном драйвере EMM386 с ключом NOEMS, вирус перезагружает
компьютер. Компьютер также может перезагрузиться, если в системе
используется драйвер QEMM386. Самое интересное в том,что если в системе
находился резидентный вирус, а потом произошла загрузка Windows 3.1x
или Windows'95, то вирус не сможет размножаться в данных операционных
средах, но при выходе в DOS, вирус опять получает управление и может
"трудиться не покладая рук". Если же вирус будет запущен в Windows DOS-
окне, то из-за отсутствия интерфейса VCPI вирус не сможет переключиться
в защищенный режим. Под OS/2 вирус - нежизнеспособен, также из-за
отсутствия VCPI. В заключение стоит отметить, что это первый известный
вирус (причем, российский), использующий защищенный (виртуальный) режим
работы процессора и не конфликтующий с операционными системами "от
Microsoft", работающими также в защищенном режиме.

Сообщение отредактировал aler - Jul 15 2006, 20:53

[drusha]

Если же вирус будет запущен в Windows DOS-
окне, то из-за отсутствия интерфейса VCPI вирус не сможет переключиться
в защищенный режим.

А разве в DOS-окне поддержка VCPI отсутствует? У меня есть программа, активно использующая VCPI (от EMM386), и она нормально работала под Win-95/98 в DOS-окне. Правда, тогда в CONFIG.SYS (ешё до загрузки виндов) стоял вызов EMM386.EXE со специфическими параметрами, как они нудны именно для этой программы (с установками по умолчанию, а так же вообще без EMM386 эта программа вообще не работала, но при инсталляции проверяла CONFIG.SYS и по мере необходимости вставляла или заменяла там вызов EMM386.EXE с такими параметрами, которые надо именно ей). Правда, всё это относится к виндам 95-98-МЕ. На NT (2000, XP) я её не проверял, да и за фигом? Всё это дела давно минувших дней.

[aler]

А разве в DOS-окне поддержка VCPI отсутствует?

1. Описание вируса писал не я - оно взято из VIRLIST'а DrWeb'а.
2. Не знаю, есть ли VCPI.
3. Кроме VCPI есть еще DPMI, который точно поддерживается, и программы обычно знают оба стандарта.

Сообщение отредактировал aler - Jul 16 2006, 17:21

[drusha]

Вообще, здесь про вирусы писать - это оффтоп.

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

Но. Наличие выразительных средств, ВСТРОЕННЫХ в этот язык - различается. Я, скажем, представляю себе, как написать на С подпрограмму, которая компилируется в эквивалентный машинный код, как получается на С++ при реализации метода некого класса.
Но я не знаю, как можно заставить его (не прибегая к инлайн-ассемблеру, на котором можен всё) передать массив по значению или возвратить из функции значение типа массива (структуры, и т.п., но не по ссылке или указателю). И чтобы это было совместимо со всеми версиями компилятора (от Microsoft, Borland, Watcom, Symantec, IBM...) А на Паскале как написать функцию, которая берёт неопределённое количество параметров... Паскале-подобные функции на С/С++ писать можно - там есть модификатор PASCAL, STDCALL или WINAPI (весь API Windows сделан по-паскалевски, ибо Си к паскалевскому стилю приспособить можно, наоборот - нет). Но всё это - детали внутренней кухни, которая может позволять или не позволять реализовывать алкогоритмы эффективнее, быстрее, жрать меньше памяти... Но по сути - ничего принципиального. И вообще, в 64-битном режиме x86-е процессоры (что Intel, что AMD) ведут себя больше похоже на RISC-процессоры типа ALPHA, SUN и иже с ними... У них там не 8, а уже 16 РОНов, сегменты отсутствуют как класс, и т.п. Там уже обретает смысл использовать ключевое слово _register...

[PINguin]

Хех, комрад drusha очевидно, забыл, что LISP - прежде всего, функциональный язык и он не столь гибок, как ASM.
Нет, например инсталлер (кому-то смешно? на AltLinux инсталлер именно на ЛИСПЕ, исходники сам видел) удобнее будет на нем написать, а не на асме.
Для "оконных приложений" он примерно так же геммороен, как и асм.
ТЕперь о переносимости- да , под UNIX синтаксис асма отличается, например, приемники и передачи менеются местами и т.д.
Однако гооврить о ПОЛНОЙ непереносимости нельзя.

[drusha]

Ну, как я уже упоминал, существуют лисп-машины, в которых он поддерживается аппаратно (фактически являясь для них их родным асмом) Я не помню, как тот комп назывался (дело было в прошлом веке), но у нас в институте такой стоял. На нём был Зета-Лисп - очень продвинутая версия Лиспа. Там и ООП реализован, и графика, и оконный интерфейс... Функциональный - это "чистый" (True)-Лисп, который практически никому не интересен (кроме чисто учебных применений).

Что касается асмов с другим синтаксисом, то это не под Unix, а под другой проц. Unix с самого начала задуман как портабельная ось под разные процы. Мне когда-то приходилось писать на Асме под VAX, PDP (СМ-4)... Так, там было 15 РОНов, 3-адресная (кажись, так, если не путаю с асмом под IBM-360/370 или наш аналог EC-1061). То есть, там в команде, которая выполняет какую-то операцию, указывается не 2 адреса, а 3: откуда взять первый и второй операнды, и куда положить результат. Его можно класть на место первого или второго, или какого-то совершенно третьего регистра...

А ещё я видел (не писал, правда) такой обобщённый ассемблер под PICK. Он, типа, портабельный. Но я не вижу смысла называть его асмом. Там уже теряется однозначная связь между строчками исходного кода и машинным кодом.

Но, имхо, сейчас уже нет смысла изучать 32-битный асм, поскольку все современные процы уже поддерживают 64 разряда, и года через 3 все 32-битные версии виндов (и линюксов, наверное) уже сдохнут. Конечно, современный Пентиум (даже с 64-битным расширением) поддерживает и 16-битный код 286-го проца (и даже реальный режим 8086/8088), но кто-нибудь под это сейчас пишет? Тем более, на 16-битном асме...

[PINguin]

Про последний абзац-
Никакой ПОЛНОЦЕННОЙ 64-битизации (я тут сфамильярничаю немного) нет. Вот во времена прехода с 16 на 32 - да, добавились регистры, полностью изменилась "техника" программирования и т.д.
А сейчас все что есть на руках - это обыкновенные 32x PE, к которым дописано несколько дополнительных секций. И "портировать" обычные EXE туда-обратно несложно.
ПРосто вся мощь архитектуры 64-х битников не применяется.
Нас просто дурят.
(подробнее можно почитать у Криса Касепрски (мыщьХ, Нецуми))
А 16-битный асм отлично подходит для первоначального обучения и знакомства с языком.

[drusha]

Как раз, в 64-битной архитектуре (доступной в 64-битном режиме) отличий от 32-битной гораздо больше, чем при переходе с 16 на 32.

Кстати, с тех пор как появилася 32-битная архитектура 80386 (кажись, 1985-86 гг прошло примерно 10 лет прежде чемпоявилась возможность использовать её в полную мощь (пришли полностью 32-битные операционки типа Win-95, OS/2 Warp 3.0). Сами 386-е процы не дожили до этих дней, тогда уже 486-е заканчивались...

А до этого с 32-битным кодом была примерно такая же петрушка, как сейчас с 64-битным. Была такая примочка DOS4G, DPMI и т.п. В обычный DOS-овский EXEшемк вставлялись сегменты (или секции), которые надлежало грузить в 32-битные сегменты защищённого режима. В свамой программе был стартовый код, который переводит проц в звщищённый режим, делает там 32-битный сегмент, грузит туда надлежащие секции программы (как будто это просто данные), оформляет сегмент как исполняемый, и передаёт туда управление...

А формат PE - потому он так и называется Portable Executable, то есть, там с самого начала предусмотрена возможность переноса на другую архитектуру... Так что, вполне возможно, что и через 10 лет этот формат будет так и называться - PE.

Так что, да, я согласен, что СЕЙЧАС никакой полноценной поддержки нет. И она будет актуальна когда количество физической оперативки на среднем компе перевалит за 2 Гб (тем более, за 4Гб). Сейчас новые компы обычно комплектуют примерно одним гигом. Двумя - это уже довольно навороченные. А четырьмя - и более это только крутые серваки, хотя в той нише гораздо крепче позиции Sun (Solaris), Unix и т.п. А до двух гигов обычные винды ещё худо-бедно потянут...