native приложение

Извинявам се за сигурно елемнтарния въпрос но четох темата VCL.NET Applications vs Windows Applications Delph и не ми е ясно какво е native приложение.Какви други типове приложения има?И ако може обяснете с две думи какво е framework a ако ми дадете и някой линк на български по темите ще съм ви благодарен.

Ами в известна степен .NET прилича на Java (надявам се знаеш какво е Java). Приложенията писани на .NET не се компилират до изпълним (native) код, който се разбира от процесора, а до междинен псевдо код (CLR мисля), а той от своя страна вече се изпълнява в някаква виртуална машина.
За литература на български не мога да ти дам линк, но иначе може да разгледаш тука:
[линк]
[линк]

Животът не се мери с броя вдишвания, а с моментите, които спират дъха ни!

Забравих това: [линк]

Тук си в лека грешка. Компилира се до така наречения Intermediate Language, който от своя страна след това се компилира до машинни инструкции.

Това е голямата разлика с Джавата - тук не става дума за виртуална машина. Технологията е различна.

Така че теоретично скоростта между native Win32 приложение и .NET такова, е почти едно и също.

с малко влакче композирам патките в реката

Да, компилира се до IL, а CLR-то всъщност е JIT компилатор (което си е точно, ама точно както е при Java-та). Това ти е MSCorEE.dll. А структурата на ено .net exe e PE хедър, CLR хедър, метаданни и (обърни внимание) IL код(!!!) (т.е. в exe-то ти никъде няма native код), който се компилира при първото си изпълнение. Така че скоростта на JIT е много по-голяма от тази на обикновен интерпретатор, но просто не виждам каква е разликата и различната технология?!

Животът не се мери с броя вдишвания, а с моментите, които спират дъха ни!

1. Ако не е на машинен код как скоростта става близка със скоростта на изпълнимите exe файлове?
2. Като е толкова обвързано с операционната система за какво му е да е да има междинен слой (Intermediate Language)? Нали интерпретаторите затова се ползват - програмите да са по-слебо обвързани с операционните системи и дори с апаратните средства?

Здравеите!
В хелпа на фреимлорка пише че и двамата не сте прави
До колкото си спомням пише че в екзето се вкючва кода за всички платформи с които е съвместимо(32 64) и в зависимост от това на каква платформа се изпълнява този код се изпълнява, като самият код си и машинен (native). По този начин това екзе върви еднакво бързо на всяка платформа но размера му съответно е по-голям .
Венцислав Александрийски.

1. Преди изпълнението на приложението от CLR и P-code (не съм напълно наясно с терминологията още) - то се транслира до машинен код. Така се избягва интерпретацията/транслирането на кода по време на изпълнение.
Съвременната Java - използва същия подход - макар, че се говори за Java virtual machine.

2. Реално обвързан е само модула който транслира до машинен код от междинния код - така приложенията стават наистина процесорно/системно независими - това разбира се е влияе на скоростта - т.е. оптимизациите за определен процесор/система тук са по слаби(и реално няма как да не са) от колкото при реалните компилатори.
Нямаш обвързаност с апаратни средства - точно за това служи фреймуорк-а - да ти даде всички необходими функции - без значение от устройството с което си комуникираш. А функцията за тази комуникация се поема от системата - т.е. за всяка ОС трябва да си има съответния .НЕТ framework.

---
Колкото повече, толкова повече.

Къде в хелпа го прочете това?! Вътре е ехе-то е IL кода...

Животът не се мери с броя вдишвания, а с моментите, които спират дъха ни!

Kakto vinagi az i bat karasko sme na edno mnenie :)
I az znam, che prilojenieto se kompilira za prav pat kato se startira vzavisimost ot harduernoto obkrajenie. Dali x86,AMD64 ili Itanium. Taka se postiga maximalna proizvoditelnost. Ne e kato JAVA-ta kadeto si e chist interepretator.

Ama nie mnogo pochnahme da obsajdame native vs. Intermediate :)

В карайна сметка кой е прав?

Филипе, преди да се изказваш така попрочети малко за JIT компилатори.

Животът не се мери с броя вдишвания, а с моментите, които спират дъха ни!

Е , и?
Това че в ЕХЕ-то има IL код, по никакъв начин не означава че се изпълнява този код - нали минава през JIT компилатора :)

с малко влакче композирам патките в реката

Е сега да не кажеш че се заяждам, ама тук точно не си прав:

"т.е. оптимизациите за определен процесор/система тук са по слаби(и реално няма как да не са) от колкото при реалните компилатори"

Напротив:

1. При стандартните компилатори се генерира код, който в по-голямата си част се ръководи от правилото да върви на всички процесори от една фамилия - да речем х86. Това означава че генерирания код не използва никакви преимущества на новите процесори, като Pentium 4 или AMD64 да речем.
От друга страна при компилацията Just In Time имаш генериране на код, който е съобразен със спецификата на конкретния процесор в машината - т.е. можеш да се възползваш, ако си с нов процесор като Pentium 4 и да използваш разширените му възможности.

2. Поради факта че програмата на .NET произвежда managed code, имаш много повече информация за кода, и съответно можеш да генерираш по-добър откъм оптимизации код, отколкото unmanaged code-а, който се генерира от Win32 приложенията.



с малко влакче композирам патките в реката

JIT компилатора :) Компилира се веднъж, а не е "chist interepretator", както твърди Филип :)

Животът не се мери с броя вдишвания, а с моментите, които спират дъха ни!

Цитирам те теб, от първия ти постинг в тази тема:

"Приложенията писани на .NET не се компилират до изпълним (native) код, който се разбира от процесора, а до междинен псевдо код (CLR мисля), а той от своя страна вече се изпълнява в някаква виртуална машина.
"

По повод на това изказване написах моето по-горе.

Допускам, че може и да не съм те разбрал - би ли пояснил?

с малко влакче композирам патките в реката

Ами имах предвид, че компилатора (не JIT, а да речем C# компилатора) не създава exe в което има машинен код...

Животът не се мери с броя вдишвания, а с моментите, които спират дъха ни!

И двете ти твърдения са теоретично вярни - единствения начин да се докаже моето или твоето твърдение - е да се провери за едно и също нещо като код - какво се генерира като машинен код от компилаторите - мисля за това си съгласен а?
Все пак се съмнявам действителността да е такава каквато я описваш - само едно ще спомена - част от manage кода включва изчистването на паметта ползвана от обектите - нещо което като код липсва в нормално генерираните програми от C компилаторите - така, че ето ти един пример защо едно .NET приложение ще бъде по-бавно от едно не.НЕТ такова ;-)))))

Още нещо за оптимизациите - не забравяй факта, че хората които сега пишат .NET компилаторите - преди това са писали и "обикновените" такива -
ако някой е искал да продуцира код за P4- то той винаги би могъл да го направи със съответния компилатор.

Няма смисъл да спорим - най-малкото, че нямаме достатъчно информация за това.

Новите неща са хубаво нещо - но не забравай - те винаги са базирани на нещо старо ;-))) - премахват някои недостатъци, но пък имат нови (обикновено по-големи - мисля историята го е потвърдила) изисквания - нищо лошо - няма в това.

---
Колкото повече, толкова повече.

Те тези езици правят Intermediate код, който после се преобразува в машинен при първото си изпълнение, което мисля е доста добре. Аз лично си държа на своето ако аз направя някакво приложение на .NET то ще се възползва максимално от процесора, на който се изпълнява, а ти трябва компилираш няколко пъти твоето ПЛЮС да го оптимизираш. .NET върши всичко това.

И все пак незабравайте, че .NET e във версия 1.1, по нататък още кой знае какви хубави неща ни очакват. Например за 2.0 чета доста хубави отзиви.

От цялата патаклама не разбрах какво толкова печелим като използваме managed code? Предполага се че няма нужда след това да си дебъгваме програмите или как? Цялата тая истерия ми е някак чужда...

------------------------------
I got a COMPILER, and I'm not afraid to use it!

>>> ако аз направя някакво приложение на .NET то ще се възползва максимално от процесора, на който се изпълнява, <<<
Точно за това говорим. Максимално е твърде силна дума. Дори и да бъде перфектно оптимизирано за архитектурата, на която се изпълнява, в самия .NET (респективно Java) има достатъчно допълнителни неща, които да ти забавят програмата в сравнение с едно чисто приложение (garbage collector-а например).

>>> а ти трябва компилираш няколко пъти твоето ПЛЮС да го оптимизираш. <<<
Като изключим мобилните устройства за колко архитектури и операционни системи има достъпен .NET, та да имаш предимството да не си компилираш програмата многократно?

>>> И все пак незабравайте, че .NET e във версия 1.1, по нататък още кой знае какви хубави неща ни очакват. Например за 2.0 чета доста хубави отзиви. <<<
Е, Java пък в момента е във версия 1.5.0 beta 2... Не е голяма разликата :)

Нека да прекратим този безсмислен спор. Никой тук не твърди, че .NET е нещо лошо. И ако двамата с ФантомАС не сме съгласни (поне и той така написа наскоро), че скоростта на .NET приложенията е същата както на native кода, то това си е наше лично мнение. Имаме все още право на мнение, нали :)
Просто искахме да кажем, че не бива да се изпада в крайности и че .NET-а колкото и да е хубав все още не става за всичко.

Животът не се мери с броя вдишвания, а с моментите, които спират дъха ни!