Версия для печати темы
Нажмите сюда для просмотра этой темы в обычном формате
Alf-Studio _ Программирование _ Языки программирования
Автор: Mr.Floppy Aug 26 2005, 14:14
Какой язык программирования по вашему мнению самый лучший? (имеются ввиду компилируемые языки)
И почему именно он?
Автор: gesper Aug 27 2005, 16:15
естественно на первом месте Ассемблер, на 2 месте у меня C++ за то что его компилятор более хорош чем делфовый в плане расхода места и скорости выполнения конечной программы.
Автор: Отец Дионисий Aug 27 2005, 16:17
Для разных задач разный.
Написать большой проект - Си
Балушку - сойдет и Дельфи, и Васик 
Автор: White P. Aug 28 2005, 09:50
у каждого свои достоинства и недостатки...
C++ предстоит выучить =)))
Автор: PINguin Aug 28 2005, 11:45
Делфи, ибо простой.
Асм, ибо классика.
Автор: gesper Aug 28 2005, 12:02
Написать большой проект - Си
Балушку - сойдет и Дельфи, и Васик
Видал я этот Васик... я с него начинал(делать нефига было ,а он тут подруку попался) и он меня порядком заканал своими подколками с библиотеками, вот делфа другое дело.. можно написать прогу и не париться что потом каких то длл хватать не будет
Автор: Mr.Floppy Aug 28 2005, 13:13
>> Для разных задач разный.
Вот именно. Дельфи больше подходит для работы с базами данных, но на нем не напишишь низкоуровневых приложений (драйверов например). Для этих задач лучше подойдет C или Asm. А VB - идея хорошая, реализация плохая - надо таскать с собой библиотети (или надеятся, что они есть) и постоянно обращаться к ним - понижается скорость работы, отсюда вывод - бейсик не подходит для написания более-менее серьезных приложений, а лучшее применение ему - макросы в M$ Оффисе! 
Java. Неплохой язык, мультиплатформенный... тормозной правда , больше ничнго сказать не могу. Assembler на сегодняшний день существует только в виде вставок в код более высокоуровневых языков. Писать прогу полностью на нем (особенно оконную под Винду) - похвально, похвально... к старости может и закончите... Лучше использовать для написания функций (вышеупомянутых asm-вставок). Си - хороший язык, только немного сложнее для изучения чем Дельфи и компилируется долго. 
Про остальные языки (фортан, ада) и говорить нечего - они давным-давно устарели и пользоваться ими нет никакого смысла (много людей сейчас перфокартами и пятидюймовыми дискетками пользуется? вот-вот...)
Автор: gesper Aug 28 2005, 14:45
Поправка небольшая: в офисе не VB ,а VBA разница большая, поверьте, месяц с ним уже маюсь.
Автор: Viper Nov 11 2005, 07:28
Меня радует Ruby, так как уже второй год его учу.
Автор: ALEXRUS Nov 11 2005, 19:01
ASSEMBLER FOREVER
вот сёдня прогу написал, которая загрузочный сектор затирает )
и может записать туда что ты захочешь вместо стёртых данных.
так и винду мона угробить )
Автор: Developer Nov 12 2005, 15:51
а помоему глупая тема..какой язык лучше???
нельзя сказать не про один язык..во всех языках програмирования свои минусы и свои плюсы...
и каждый язык создан дял каких-то целей...
например чистое самоубийство на ассемблере 3D-action писать..или на VB Windows!!! так что тут кто какой предпочитает..и всё..
Автор: ALEXRUS Nov 12 2005, 20:00
на асме писать 3D-action самый раз
только долго писать надо будет.
зато игра будет ресурсов меньше жрать.
Автор: Конан Nov 12 2005, 21:46
Асемблер и C++
Автор: iNcluDe Jan 6 2006, 23:44
С программирование сталкивался довольно редко, но основные задачи решал на
Delphi, Perl, PHP
Сейчас больше всего интересуюсь дельфёй =)
Автор: Pugnator Jan 8 2006, 03:27
ну и опрос......что лучше запорожец или феррари?
хех, по даче ездить - запор, девчонок кадрить - феррари =)))
вот щас для меня актуален MPASM- ассемблер микроконтроллеров фирмы microchip.
А так - Java (не путать с javaScript)
Автор: FLoODY Mar 4 2006, 21:42
СИ++
Автор: ismolnik Mar 5 2006, 02:23
JavaSript & Java
Автор: Tassadar Mar 6 2006, 19:12
Си ща учу...круто))))
Автор: ismolnik Mar 6 2006, 19:53
Java
Автор: drusha Jun 23 2006, 22:06
Для работы - Borland C++ Builder. Но потихоньку перехожу на мелкософтовские вещи. Под 64 разряда Борланд уже ничего не сделает. Его уже нет.
А лоя души - ЛИСП!!! Я сам когда-то написал интерпретатор для языка Лисп (и назвал его Топо-ЛИСП. Правда, он под DOS, 16 разрядов. Правда, там используется XMS, EMS, свопинг на диск и бездонный виртуальный стек...
Автор: dark-ila Jun 24 2006, 01:06
C/C++ и спорить даже неочем!
Автор: proT0N Jun 25 2006, 18:04
+1
А как насчет C# ?
Автор: dark-ila Jun 28 2006, 09:01
Забыл впихнуть его в мой список....
тогда:
Автор: proT0N Jun 29 2006, 13:59
Забыл впихнуть его в мой список....
тогда:
не совсем так...
C++ и C# - немного разные языки, но они оба основаны на C
Автор: dark-ila Jun 30 2006, 21:51
=> C рулит!
Автор: aler Jul 5 2006, 19:59
Паскаль - для user-программ
Ассемблер - для системных
может еще Java (для UNIX/Linux)
Автор: drusha Jul 6 2006, 22:56
В АссемБЛЕре я разочаровался. Он абсолютно непереносим. Скоро 32-разрядная архитектура и вовсе сдохнет, тогда ассемблер другой понадобится. "С" более переносим, даже на другие процессоры, а системные проги (даже драйверы) можно писать на нём (я писал VXD под Win-95/98 на С, но не ++, надо только слинковать с маленьким модулем, написанном на Ассемблере). Если привые к С/С++, то можно всё что угодно. Раньше я писал на Паскале. Паскаль более дубовый язык, но и на нём многое можно. Например, имхо, Borlsnd C++ Builder очень портит дельфёвая реализация VCL.
Напрягает разнообразие языков. Когда приходится одну прогу (но разные её модули) писать на C--/С++, Паскале (Дельфи), Бейсике (VBA), SQL и Ассемблере... Ну, нафига, спрашивается?... Я думаю, что будущее за С-подобными языками, к которым я отношу и джаву. Ну, сама джава - это больше для апплетов и серверлетов...
Yj lkz leib - dc` hfdyj - LISP? b njkmrj LISP!!!
Автор: Frut Jul 7 2006, 19:04
LISP)) это же вроде бы алгоритмический язык?
Автор: drusha Jul 8 2006, 12:53
Ну, да! Конечно.
Когда-то я писал на AutoLISP под AutoCAD. Если кому-нибудь интересно, могу дать свою программу, которая реализована на AutoLISP, и она в среде AutoCAD реализует моделирование оптических систем. Можно расчитывать оптические системы любой сложности. Но больше она ориентирована на любительское телескопостроение.
Могу также поделиться вирусом, который я написал на АвтоЛИСПе
Ещё я когда-то написал собственный интерпретатор языка LISP, который называется TopoLISP. Там поддерживается управление топологией списков. И что интересно, хоть Лисп означально не имеет поддержки объектно-ориентированной парадигмы, но достаточно было написать небольшой модуль на самом Лиспе, как среда этого языка стала объектно-ориентированной!
На Лиспе хорошо писать системы искусственного интеллекта.
А ещё Лисп обладает удивительными свойствами. Например, можно написать интерпретатор Лиспа на самом Лиспе. Легко на нём пишутся автоаппликативные и авторепликативные программы, а так же программы с самомодифицирующимся кодом. Короче, Лисп - это идеальная среда для вирусов, червяков и прочей виртуальной живности. Да к тому же, с искусственным интеллектом!
Автор: aler Jul 9 2006, 19:02
В АссемБЛЕре я разочаровался. Он абсолютно непереносим. Скоро 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 Jul 12 2006, 20:56
Лично мне - лень под каждую платформу. Тем более, которой пока ещё нет. А хочется чего-то вечного, чтоб сразу на века... Ну, как наши предки делали. Самолёты Ил-14, Ил-18 до сих пор кое-где летают... Ракета Р-7 (это первые две ступени, которые вывели первый Спутник, а в зависимости от третьей ступени она называлась "Восток", "Союз", "Молния"...) тоже летает до сих пор... Вот, хотелось бы чтобы и программы такими же были... Но, вот, что есть насчёт даты-времени в стандартной библиотеке (stdlib) ANSI-стандарта языка C (из С++/С# её функции также доступны), всё это будет правильно работать где-то до 2038 года. То есть, грядёт "проблема 2038 года", и тогда многие программы, написанные на С/С++, единомоментно сдохнут. Это касается 16- и 32-разрядных платформ Windows (подозреваю, что и под UNIX тоже, и даже MAC OS). Возможно, в 64-разрядных версиях эта проблема уже не стоит. Проживёт ли архитектура 16/32 разряда ещё 30 лет - я не знаю. Но многие предметы 30-летней давности (не только самолёты и ракеты, но иавтомобили, мотоциклы, холодильники, велосипеды, фотоаппараты, телевизоры, радиоприёмники, катушечные магнитовоны и проигрыватели виниловых дисков) не только работают, но и во многом превосходят современные аналоги.
Насчёт ассемблера.
Кстати, есть (не очень, правда, распространены) лисп-машины, пролог-машины... Там такие языки как Лисп (конкретно, Зета-лисп), Пролог и т.п. поддерживаются на аппаратном уровне: по сути они являются для них ассемблерами.
Автор: OXOTHuK-SM Jul 15 2006, 15:35
Я думаю если СССР прожил на десяток лет больше то наши программисты точно написали бы супер программы на века думаю что были бы у нас самые лучшее вирусы и трояны для взлома американских компов в белом доме
На счёт языков я не знаю не один кроме языка для написания web странниц и то плохо знаю
Автор: aler Jul 15 2006, 20:48
Я думаю если СССР прожил на десяток лет больше то наши программисты точно написали бы супер программы на века думаю что были бы у нас самые лучшее вирусы и трояны для взлома американских компов в белом доме
На счёт языков я не знаю не один кроме языка для написания 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", работающими также в защищенном режиме.
Автор: drusha Jul 16 2006, 14:58
Если же вирус будет запущен в 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 Jul 16 2006, 17:19
А разве в DOS-окне поддержка VCPI отсутствует?
1. Описание вируса писал не я - оно взято из VIRLIST'а DrWeb'а.
2. Не знаю, есть ли VCPI.
3. Кроме VCPI есть еще DPMI, который точно поддерживается, и программы обычно знают оба стандарта.
Автор: drusha Jul 17 2006, 21:51
Вообще, здесь про вирусы писать - это оффтоп.
А так, чисто теоретически, все языки, обладающие тьюринг-полнотой - эквивалентны. По этому поводу есть "тезис Чёрча". То есть, любой алкогоритм, который можно выразить на одном тьюринг-полном языке, можно и на любом другом таком же.
Но. Наличие выразительных средств, ВСТРОЕННЫХ в этот язык - различается. Я, скажем, представляю себе, как написать на С подпрограмму, которая компилируется в эквивалентный машинный код, как получается на С++ при реализации метода некого класса.
Но я не знаю, как можно заставить его (не прибегая к инлайн-ассемблеру, на котором можен всё) передать массив по значению или возвратить из функции значение типа массива (структуры, и т.п., но не по ссылке или указателю). И чтобы это было совместимо со всеми версиями компилятора (от Microsoft, Borland, Watcom, Symantec, IBM...) А на Паскале как написать функцию, которая берёт неопределённое количество параметров... Паскале-подобные функции на С/С++ писать можно - там есть модификатор PASCAL, STDCALL или WINAPI (весь API Windows сделан по-паскалевски, ибо Си к паскалевскому стилю приспособить можно, наоборот - нет). Но всё это - детали внутренней кухни, которая может позволять или не позволять реализовывать алкогоритмы эффективнее, быстрее, жрать меньше памяти... Но по сути - ничего принципиального. И вообще, в 64-битном режиме x86-е процессоры (что Intel, что AMD) ведут себя больше похоже на RISC-процессоры типа ALPHA, SUN и иже с ними... У них там не 8, а уже 16 РОНов, сегменты отсутствуют как класс, и т.п. Там уже обретает смысл использовать ключевое слово _register...
Автор: PINguin Jul 22 2006, 11:41
Хех, комрад drusha очевидно, забыл, что LISP - прежде всего, функциональный язык и он не столь гибок, как ASM.
Нет, например инсталлер (кому-то смешно? на AltLinux инсталлер именно на ЛИСПЕ, исходники сам видел) удобнее будет на нем написать, а не на асме.
Для "оконных приложений" он примерно так же геммороен, как и асм.
ТЕперь о переносимости- да , под UNIX синтаксис асма отличается, например, приемники и передачи менеются местами и т.д.
Однако гооврить о ПОЛНОЙ непереносимости нельзя.
Автор: drusha Jul 22 2006, 12:19
Ну, как я уже упоминал, существуют лисп-машины, в которых он поддерживается аппаратно (фактически являясь для них их родным асмом) Я не помню, как тот комп назывался (дело было в прошлом веке), но у нас в институте такой стоял. На нём был Зета-Лисп - очень продвинутая версия Лиспа. Там и ООП реализован, и графика, и оконный интерфейс... Функциональный - это "чистый" (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 Jul 22 2006, 12:28
Про последний абзац- 
Никакой ПОЛНОЦЕННОЙ 64-битизации (я тут сфамильярничаю немного) нет. Вот во времена прехода с 16 на 32 - да, добавились регистры, полностью изменилась "техника" программирования и т.д.
А сейчас все что есть на руках - это обыкновенные 32x PE, к которым дописано несколько дополнительных секций. И "портировать" обычные EXE туда-обратно несложно.
ПРосто вся мощь архитектуры 64-х битников не применяется.
Нас просто дурят.
(подробнее можно почитать у Криса Касепрски (мыщьХ, Нецуми))
А 16-битный асм отлично подходит для первоначального обучения и знакомства с языком.
Автор: drusha Jul 22 2006, 16:10
Как раз, в 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 и т.п. А до двух гигов обычные винды ещё худо-бедно потянут...
Автор: aler Jul 28 2006, 19:04
Но, имхо, сейчас уже нет смысла изучать 32-битный асм, поскольку все современные процы уже поддерживают 64 разряда, и года через 3 все 32-битные версии виндов (и линюксов, наверное) уже сдохнут. Конечно, современный Пентиум (даже с 64-битным расширением) поддерживает и 16-битный код 286-го проца (и даже реальный режим 8086/8088), но кто-нибудь под это сейчас пишет? Тем более, на 16-битном асме...
Я пишу
Как раз, в 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 и т.п. А до двух гигов обычные винды ещё худо-бедно потянут...
1. Процессоры начиная с Pentium Pro(P6), кроме некоторых Celeron'ов, поддерживают до 64ГБ памяти - проблема с 4Г связана не с процессором а с другими частями компьютера.
2. Многие черты 64-битности появились уже во вторых пентиумах - поддержка адресации более 4Г, 64-битная шина данных, некоторые 64- и даже 128-битные инструкции.
Автор: drusha Aug 1 2006, 13:59
Доступ к 64 Гбайтам памяти в P6 возможен за счёт 64 режима кбайтных страниц, который в Windows не используется. К тому же, в 32-битном режиме в одном 32-битном сегменте может быть не более 4 Гб памяти. А Win-32 приложений характерна FLAT-модель памяти, когда всё в одном сегменте (вернее, есть сегмент команд и сегмент данных, база и размер которых совпадают) - то есть, всё происходит в линейном адресном пространстве размером не более 4 Гб. На самом деле, Windows ограничена ещё больше: процессу она даёт не более 2 Гб, а ещё 2 Гб резервирует для своих нужд (там сидят драйверы уровня ядра, видеобуфер и всё такое). Конечно, по идее, даже при таком раскладе на компе, у которого 64 Гб физической памяти, можно было бы запустить 32 процесса (каждый в своём адресном пространстве), и каждому дать по 2 Гб... На самом деле, то же самое можно получить с использованием файла подкачки (и имея жёсткий диск размером более 64 Гбайт) даже на 386-м процессоре. На 64 Гб физической памяти будет пошустрее, и всё.
А спич я веду про то, чтобы дать ОДНОМУ ПРОЦЕССУ (например, крутому серверному процессу) более 4 Гб физической оперативки. Или хотя бы виртуальной. Но 32-битные версии Windows не способны даже на это. А между тем, уже даже 512-мегабайтным видеобуфером сейчас никого не удивишь. Скоро 2 (или даже 4) Гбайта адресного пространства (даже виртуального) будут как бревно в глазу, как 640 Кбайт в DOSовские времена... Но тут уже нужна другая операционка. Среда Win32 не пойдёт.
Автор: mars Jan 9 2007, 00:09
По-моему, для программера (особенно ленивого, типа меня ) лучше всего Java,
ибо там навалом всяких примочек, облегчающих программерскую жизнь.
Правда, туда ещё надо нормальный IDE, я использую Eclipse.
С точки зрения юзера, особ. если у него медленный / не очень быстрый комп, то
лучше, наверное, будет Delphi или CPP.
Автор: VenDettKA Dec 2 2007, 00:11
Я вот думаю, мне басик учить или сразу С++? Програмеры говорят, что бэйсик ща сосёт.
Автор: wirr Dec 2 2007, 15:43
бэйсик всегда сосал.
Дельфи лучше учи
Автор: VenDettKA Dec 2 2007, 17:32
Ну у меня ещё полгода есть для принятия решения. ))) Буду иметь ввиду. А чем дельфи хорош?
Автор: wirr Dec 2 2007, 17:42
Ну вообще, надо решить, ЧТО ты будешь программировать, собственно
Делфи - виндовые проги. Я не пишу на нем потому, что, в основном, в клепаемых мною прогах, используется Qt. Мне так удобнее.
Дельфи чем хорош? В Делфи можно быстро написать что-то простое или среднего уровня сложности. Например, qip написан на дельфи, если не ошибаюсь. А если собираешься писать что-то конкретно серьезное и большое... Си сложнее в разы.
Автор: ismolnik Dec 2 2007, 23:08
Доступ к 64 Гбайтам памяти в P6 возможен за счёт 64 режима кбайтных страниц, который в Windows не используется. К тому же, в 32-битном режиме в одном 32-битном сегменте может быть не более 4 Гб памяти. А Win-32 приложений характерна FLAT-модель памяти, когда всё в одном сегменте (вернее, есть сегмент команд и сегмент данных, база и размер которых совпадают) - то есть, всё происходит в линейном адресном пространстве размером не более 4 Гб. На самом деле, Windows ограничена ещё больше: процессу она даёт не более 2 Гб, а ещё 2 Гб резервирует для своих нужд (там сидят драйверы уровня ядра, видеобуфер и всё такое). Конечно, по идее, даже при таком раскладе на компе, у которого 64 Гб физической памяти, можно было бы запустить 32 процесса (каждый в своём адресном пространстве), и каждому дать по 2 Гб... На самом деле, то же самое можно получить с использованием файла подкачки (и имея жёсткий диск размером более 64 Гбайт) даже на 386-м процессоре. На 64 Гб физической памяти будет пошустрее, и всё"
Да, это точно
Автор: mars Jan 1 2008, 05:18
Java удобнее, так как поддерживается практически всеми платформами. Например, я написал прогу на Java, она работает на x86, на ARM (PocketPC, Windows Mobile 2003 + Jeode Runtime), плюс с использованием тех же классов, переписав только интерфейс и ввод-вывод, можно запускать на мобильнике.
Правда тут есть свои заморочки, например на КПК не поддерживается Swing, только Awt.
Автор: proton Jan 1 2008, 09:54
Java удобнее, так как поддерживается практически всеми платформами. Например, я написал прогу на Java, она работает на x86, на ARM (PocketPC, Windows Mobile 2003 + Jeode Runtime), плюс с использованием тех же классов, переписав только интерфейс и ввод-вывод, можно запускать на мобильнике.
Правда тут есть свои заморочки, например на КПК не поддерживается Swing, только Awt.
С Си тоже самое, только там компилировать надо)
Автор: Metallica May 6 2018, 01:04
сейчас бы 2005 год и на C# и php писать
Автор: Tier May 7 2018, 08:11
Антон собирается
Автор: Metallica May 7 2018, 11:31
Что собирается ? учить чтоле ?
Я думаю у Антона получились бы арты необычные . в силу его необычного восприятия
Автор: Tier May 7 2018, 12:53
Ну с#
Автор: Metallica May 7 2018, 21:58
C# ну я думаю это продлиться не долго
очень сложно , но зато плюсы есть доки на русском
ну это все такое вилами по воде , все архитектуры только на англ можно читать
в каакой хоть области , десктоп , сервер или юнити это вонючее
все это слишком годо затратно
Автор: Tier May 7 2018, 22:54
Ну ты приезжай выясни у него сам, объяснишь ему по белорусски
Автор: ismolnik May 24 2018, 12:53
Антон собирается
Женя, как пишется ник Антона?