Компьютерный флуд

spoilt · 11-02-10 14:06:31

Windows CE

На этом поделии можно запустить GiMP? Или полноценную Opera? Для нетбуков нужна полноценная (но с оптимизацией интерфейса) ОС.

Jazz · 11-02-10 14:16:15

spoilt пишет:

На этом поделии можно запустить GiMP? Или полноценную Opera? Для нетбуков нужна полноценная (но с оптимизацией интерфейса) ОС.

GIMP'у не найдётся место, скорее всего. Ему на замену будет Paint.NET. А браузеры портируют, если приспичит. Чего это GIMP на Android не запускается? wink Для него все приложения с нуля писались, вот и для Windows CE напишут, если разработчикам будет выгодно. smile

MOP3E · 11-02-10 14:36:49

А в чём, собственно, проблема? Если программа написана на языке высокого уровня, и уж тем более на .Net, думаю, не составит особых проблем её портировать на ARM. Тем более, что Майкрософт перед выходом винды для ARM постарается оповестить всех девелоперов. smile

Jazz · 11-02-10 14:38:42

MOP3E пишет:

Тем более, что Майкрософт перед выходом винды для ARM постарается оповестить всех девелоперов.

+1
Microsoft умеет поддержать разработчиков, как никто другой.

IvanOFF · 11-02-10 14:43:08

Главной и пожалуй единственной серьезной проблемой в портировании Windows 8 на ARM я вижу проблему с запуском на ARM приложений написанных под архитектуру x86. Остро стоит и проблема с драйверами, но мне кажется именно проблема переносимости приложений является главным препятствием в выпуске Windows 8 на ARM.

Единственной серьезной проблемой могут стать драйвера. Проблем с приложениями не будет, т.к. они не работают с железом напрямую (кроме некоторых, ставящих свои драйвера или использующих недокументированные функции) а через Win32Api который в свою очередь общается с ядром через HAL, для поддержки ARM достаточно написать новое ядро и HAL.

spoilt · 11-02-10 16:23:07

GIMP'у не найдётся место, скорее всего. Ему на замену будет Paint.NET.

Боюсь меня не устроит Paint.NET.

Проблем с приложениями не будет, т.к. они не работают с железом напрямую

Вы серьезно такую херню спороли?

IvanOFF · 11-02-10 21:18:19

Вы серьезно такую херню спороли?

Я серьезен как никогда. Если вы считаете по другому готов выслушать вашу аргументированную позицию.

spoilt · 11-02-10 21:33:32

IvanOFF, если по вашему проги запускаются независимо от железа, то попробуйте на WinXP в связке с Itanium`ом запустить обычные программы (х86 и без эмуляций). Оперативно отписывайтесь об успехах.

spoilt · 11-02-10 21:43:42

Hedge, WinXP была портирована на Itanium.

spoilt · 11-02-10 21:57:33

дадут Itanium на пару часиков поэкспериментировать))

В принципе анологичный эффект можно наблюдать при попытке запуска 64-битного приложения на 32-битной ОС.

IvanOFF · 11-02-10 22:19:35

А будет ли она там вообще работать?..

Будет.

WinXP была портирована на Itanium.

Не WinXP а WinXP 64-bit edition, которая по сути Server 2003

В принципе анологичный эффект можно наблюдать при попытке запуска 64-битного приложения на 32-битной ОС.

Вы здесь путаете разрядность ОС с аппаратной архитектурой. 64-битная система в принципе не способна исполнять 32-битный код кроме как в режиме эмуляции, от архитектуры это никоим образом не зависит. Родным для 64 битных версий Windows является win64api, win32api обрабатывается эмулятором win32api. 64-битные приложения будут без проблем работать в среде Windows как на x86-64 так и на IA64 без эмуляции.

spoilt · 11-02-10 22:30:47

WinXP 64-bit edition

Да, когда с Itanium прогорело, то решили выкинуть ее на десктопы.

Вы здесь путаете разрядность ОС с аппаратной архитектурой.

Суть не в разрядности, а в том что скомпилированный код будет отличатся. Вот и все. Если бинарник скомплирован под х86, то он и прибит туда гвоздями навечно. Чтобы запустить на ARM понадобится перекомпиляция под ARM. Исключением разве что являются программы на интепретируемых языках и байткод.

64-битная система в принципе не способна исполнять 32-битный код кроме как в режиме эмуляции

Шутишь? Прослойка есть, но никак не эмуляция. Просто идет разкидывание приложений по разрядности по разным путям и тд. Вдобавок все процы х64 могут динамично исполнять обычный х86 код.

64-битные приложения будут без проблем работать в среде Windows как на x86-64 так и на IA64 без эмуляции.

IA-64?! Товарищ, вообще-то IA64=Itanium=EPIC=проблемы с ассортиментом приложений.

IvanOFF · 11-02-10 22:42:57

Вот и все. Если бинарник скомплирован под х86, то он и прибит туда гвоздями навечно.

Каким образом он компилируется под конкретную архитектуру? Бинарник что, к регистрам процессора напрямую обращаться начинает, минуя winapi?

Шутишь? Прослойка есть, но никак не эмуляция. Просто идет разкидывание приложений по разрядности по разным путям и тд. Вдобавок все процы х64 могут динамично исполнять обычный х86 код.

А чем по вашему является WOW64? Не нравится слово эмуляция, назовите подсистемой, смысл от этого не меняется. Пример тому 64-битная версия Linux, в которую никоим образом не установишь пакет для 32 битной версии, с чего бы так?

IA-64?! Товарищ, вообще-то IA64=Itanium=EPIC=проблемы с ассортиментом приложений.

Да, я про Итаниум. Проблемы с ассортиментом приложений там в другом, при стоимости систем на Итаниуме гонять на них x86 код, не использующий все возможности архитектуры, мягко говоря глупо, да и разрабатывался он не для массового рынка. А нативных приложений под Итаниум действительно мало, причина та же - крайне малый обьем рынка.

spoilt · 11-02-10 22:56:46

Каким образом он компилируется под конкретную архитектуру?

Опа! А вы не знали что машкоды для каждой архитектуры проца разные?

Бинарник что, к регистрам процессора напрямую обращаться начинает, минуя winapi?

Он не менует WinAPI. API - это набор сервисов для функционирования программы. Например системные вызовы и тд. Но код бинарника исполняется на процессоре (так сказать ему выдается процессорное время).

А чем по вашему является WOW64?

WOW64 - это подсистема виртуализации структуры системного окружения для 32-битных программ. Это подсистема сделана всего лишь для того чтобы разграничить коды разных разрядностей.

Пример тому 64-битная версия Linux, в которую никоим образом не установишь пакет для 32 битной версии, с чего бы так?

А у меня ставило. Облом?

Да, я про Итаниум.

Ну хоть в этом сошлись.

на Итаниуме гонять на них x86 код

Мало того что стоимость Итаниумов заоблачна, так и исполнение х86 кода было очень тормознутым.

А нативных приложений под Итаниум действительно мало, причина та же - крайне малый обьем рынка.

Причины:
- Высокая стоимость итогового решения.
- Отсутствие обратной совместимости с х86 (он не мог динамически переключатся на х86).
- Наличие конкурента в виде х86-64.

IvanOFF · 11-02-10 23:03:12

Еще добавлю.

Итаниум изначально разрабатывался для высокопроизводительных систем без оглядки на совместимость с архитектурой x86 и предусматривает изначально другие принципы работы ПО. Реализовать весь потенциал Итаниума может только ПО написанное специально под эту платформу. Но несмотря на это x86 приложения на Итаниуме работают, только гонять их там никто не будет, слишком дорогое удовольствие выходит.

ARM в противоположность Итаниуму очень простой RISC процессор, никаких принципиально иных принципов работы ПО не предусматривает. Кто мешает выполнить трансляцию CISC команд архитектуры x86 в RISC команды ARM на уровне ядра ОС? Тем более все современные x86 процессоры являются гибридными, формально CISC они используют вычислительные ядра RISC архитектуры, преобразуя команды внутренним транслятором.

На сегодняшний день сдерживающий фактор один - низкая производительность ARM процессоров, поэтому выгоднее написать несовместимый код именно под эту платформу, пожертвовав совместимостью в пользу производительности.

IvanOFF · 11-02-10 23:06:21

Опа! А вы не знали что машкоды для каждой архитектуры проца разные?

Каким образом это относится к приложению? Ему до фонаря какой там код.

Он не менует WinAPI. API - это набор сервисов для функционирования программы. Например системные вызовы и тд. Но код бинарника исполняется на процессоре (так сказать ему выдается процессорное время).

Бинарник не может напрямую обратится к процессору без посредников в виде winapi и HAL, а вот в их задачу входит уже обращение к аппаратным ресурсам.

spoilt · 11-02-10 23:16:08

Каким образом это относится к приложению? Ему до фонаря какой там код.

Тогда скачай приложение под Itanium и попробуй запустить на винде (х86-64). Пока не запустишь, можешь даже не вылезать с подобными заявками.

Бинарник не может напрямую обратится к процессору без посредников в виде winapi и HAL

Ну да. Напрямую в проц он сунутся не может. Но тем не менее продя все стадии его код в итоге загружается в процессор (процессорное время, планировшик ОС и тд, можешь посмотреть в вики).

Невропаразитолог · 11-02-10 23:59:10

Если язык не asm, то да. Но компилятор загоняет код под архитектуру.

Эк, минуточку, ладно, оставим Itanium, возьмите Intel и AMD. логика почти одинаковая, но в AMD есть 3DNow! (ну, была, была) Какой адиот, зная, что это расширение логики есть не везде, будет писать именно только под него без вариантов? Вон, легендарный Winamp приспосабливался: есть MMX- хорошо, нет - обойдёмся, есть SSE - хорошо, нет - обойдёмся то же самое и про 3D Now!. (Пример хоть и старый но точный)

IvanOFF · 12-02-10 10:46:26

Давайте не трогать Итаниум, это вообще другая область, со своими законами и правилами. К рынку ПК она относится примерно также как космическая отрасль к сельскому хозяйству. Коротко поясню. Архитектура IA-64 предусматривает принципиально иной тип вычислений нежели x86, в основном связано с многопоточностью и многопроцессорностью, нативные приложения под IA-64 не используют winapi, там своя система вызовов. Однако версии Windows для Интаниум поддерживают winapi, но не наоборот. Да и какой смысл настольной ОС поддерживать вызовы IA-64? Там софт явно не для прикладных задач и стоит весьма немалые суммы.

Это только гарантирование исполнения машинного кода. Суть в том что у всех ОС есть свой API. В API есть функции спецефичные какой-то ОС (системные вызовы, различные библиотеки и тд).

Winapi, в отличии от api Linux, обладает обратной совместимостью, что позволяет использовать программы написанные для старых версий ОС в новых.

Ну да. Напрямую в проц он сунутся не может. Но тем не менее продя все стадии его код в итоге загружается в процессор (процессорное время, планировшик ОС и тд, можешь посмотреть в вики).

Здесь вы не совсем правы, загружается не его код, а трансляция его кода в команды конкретного процессора. Простой пример. У нас стоит система на базе процессора с MMX, вызовы мультимедийного приложения транслируются в команды с использованием MMX инструкций, тут мы этот процессор вынимаем и вставляем без MMX, у нас бинарник перестанет работать? Нет, его вызовы будут транслироваться в систему команд этого процессора, вместо MMX инструкций будут использовать заменяющие их последовательности простых команд, доступных данной архитектуре.

Есть 3DNow! / MMX / SSE - хорошо, будем их использовать. Нет - ничего страшного, обойдемся простыми командами.

ARM, как я уже говорил, очень простая архитектура. Набор команд весьма невелик, сделать трансляцию CISC команд x86 в RISC команды ARM задача несложная. Единственное препятствие на сегодня - низкая производительность ARM процессоров, потому как каждая CISC команда будет разложена на несколько RISC команд возможно значительное снижение производительности. Именно по этому сегодня выгоднее писать ПО именно под ARM, без оглядки на совместимость.

spoilt · 12-02-10 12:21:47

Winapi, в отличии от api Linux, обладает обратной совместимостью, что позволяет использовать программы написанные для старых версий ОС в новых.

Вмсысле? На линухе отваливается весь софт с каждым релизом ядра? Нет. (если конечно не считать 2.4).

Здесь вы не совсем правы, загружается не его код, а трансляция его кода в команды конкретного процессора.

big_smile И что их транслирует (ни слова про трансляцию в RISC это идет намного глубже в проц)? Уважаемый, вы кажется путаете машкод с байткодом. И еще тебе для размышлений, если в компиляторе не будет поддержки MMX, то фигас два твоя прога будет его использовать, уловил?

ARM, как я уже говорил, очень простая архитектура.

Тем не менее чтобы запускать на ней программы нужно их перекомпилить под ARM.
А пока программа самообразования для пользователей StopLinux:
ru.wikipedia.org/wiki/Машинный_код
ru.wikipedia.org/wiki/Компилятор
ru.wikipedia.org/wiki/Байткод
ru.wikipedia.org/wiki/Портирование
ru.wikipedia.org/wiki/ARM_(архитектура)

Отредактировано spoilt (12-02-10 13:13:19)

IvanOFF · 12-02-10 22:17:17

Тем не менее чтобы запускать на ней программы нужно их перекомпилить под ARM.

Это еще не говорит ни о чем, о причинах именно такого положения вещей я уже писал выше.

И что их транслирует (ни слова про трансляцию в RISC это идет намного глубже в проц)?

HAL, с которым приложение общается посредством подсистемы win32api.

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

Простой эксперимент, сменим HAL с поддержкой ACPI на HAL без ACPI, система тут же забудет о том, что она умеет управлять питанием, убейтесь хоть головой об стену, но ни одно приложение не сможет использовать ACPI функции.

И еще тебе для размышлений, если в компиляторе не будет поддержки MMX, то фигас два твоя прога будет его использовать, уловил?

Естественно не будет, потому вызовы системные вызовы использующие такие функции использоваться не будут.

Уважаемый, вы кажется путаете машкод с байткодом.

Не путаю. Вы путаете. Бинарный код приложения и машинный код процессора вещи разные. Компилятор транслирует язык высокого уровня на язык близкий к машинному. Перевод инструкций машинно-ориентированного языка в набор команд для конкретного процессора осуществляется на уровне HAL.

spoilt · 12-02-10 22:41:34

HAL, с которым приложение общается посредством подсистемы win32api.

ru.wikipedia.org/wiki/Hardware_abstraction_layer
support.microsoft.com/kb/99588
Найди в этих статьях слова "HAL транлсирует код" или что-то вроде. Долго будешь искать. Если не найдешь, то поищи достойный пруфлинк.

ни одно приложение не сможет использовать ACPI функции.

Естественно. Потому что это входит в функции ядра. Это как noacpi в Линухе.

системные вызовы

Вызовы MMX входят в бинарный код приложения.

Машинный код приложения и машинный код процессора вещи разные.

Еще раз прочитай про байткод.

на язык близкий к машинному.

Язык близкий к машинному - это и есть байткод.

Отредактировано spoilt (12-02-10 22:44:25)

IvanOFF · 12-02-10 23:03:48

Вызовы MMX входят в бинарный код приложения.

Если вы продолжаете настаивать, расскажите мне, опираясь на приведенную выше схему, каким образом приложение работает с MMX инструкциями процессора.

Найди в этих статьях слова "HAL транлсирует код" или что-то вроде. Долго будешь искать. Если не найдешь, то поищи достойный пруфлинк.

Вы читать умеете? Во втором линке английским по белому написано, что ни одно приложение не может обратится к железу напрямую, оно может только использовать вызовы HAL. Вызовы HAL являются универсальными и не зависят от конкретного железа, так откуда же берется машинный код для процессора? И какие, по вашему, функции исполняет HAL?

Если не найдешь, то поищи достойный пруфлинк.

М. Руссинович, Д. Соломон
Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP, Windows 2000. Мастер-класс

www.ozon.ru/context/detail/id/2427699/

spoilt · 12-02-10 23:20:47

www.ozon.ru/context/detail/id/2427699/

На засчитано. У вас MSDN кончился?

каким образом приложение работает с MMX инструкциями процессора.

Прямым. MMX - это блок процессора. Для таких вещей есть машинный код.

ни одно приложение не может обратится к железу напрямую

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

И какие, по вашему, функции исполняет HAL?

По вашему представлению HAL - это большая железобетонная стена с вооруженной охраной. Но нет. HAL - это просто еще один слой абстракции между ядром и железом. Сделан был исключительно с целью унифицировать обращение с железом. Больше всего HAL облегчает жизнь писателям дров. Но трансяция машкода одной архитектуры в другую никогда не входила в его обязанности.

Отредактировано spoilt (12-02-10 23:22:09)

IvanOFF · 12-02-10 23:27:09

У меня складывается мнение, что вы где-то нахватались верхушек. Почему моя отсылка к одной из лучших книг по архитектуре NT вам не подходит? Вас более утраивает абзац на MSDN?

Прямым. MMX - это блок процессора. Для таких вещей есть машинный код.

Смеяться при слове лопата? Если вы имеете такие глубокие познания, то разъясните мне, сирому и убогому, каким именно образом и посредством какого механизма приложение уровня Win32 Application обращается напрямую к ЦП. Схема приведена выше.

Форум StopLinux

Объявление

#1 11-02-10 14:06:31

Компьютерный флуд

#2 11-02-10 14:16:15

Re: Компьютерный флуд

#3 11-02-10 14:36:49

Re: Компьютерный флуд

#4 11-02-10 14:38:42

Re: Компьютерный флуд

#5 11-02-10 14:43:08

Re: Компьютерный флуд

#6 11-02-10 16:23:07

Re: Компьютерный флуд

#7 11-02-10 21:18:19

Re: Компьютерный флуд

#8 11-02-10 21:33:32

Re: Компьютерный флуд

#9 11-02-10 21:43:42

Re: Компьютерный флуд

#10 11-02-10 21:57:33

Re: Компьютерный флуд

#11 11-02-10 22:19:35

Re: Компьютерный флуд

#12 11-02-10 22:30:47

Re: Компьютерный флуд

#13 11-02-10 22:42:57

Re: Компьютерный флуд

#14 11-02-10 22:56:46

Re: Компьютерный флуд

#15 11-02-10 23:03:12

Re: Компьютерный флуд

#16 11-02-10 23:06:21

Re: Компьютерный флуд

#17 11-02-10 23:16:08

Re: Компьютерный флуд

#18 11-02-10 23:59:10

Re: Компьютерный флуд

#19 12-02-10 10:46:26

Re: Компьютерный флуд

#20 12-02-10 12:21:47

Re: Компьютерный флуд

#21 12-02-10 22:17:17

Re: Компьютерный флуд

#22 12-02-10 22:41:34

Re: Компьютерный флуд

#23 12-02-10 23:03:48

Re: Компьютерный флуд

#24 12-02-10 23:20:47

Re: Компьютерный флуд

#25 12-02-10 23:27:09

Re: Компьютерный флуд

Подвал форума