Здравствуйте, Edvard_Grieg, Вы писали:
E_G>Извините что беспокою с довольно глупыми вопросами НО: E_G>Мне интнересно следующее: E_G>1) Как мелкомягкие будут отказываться от вин32, если E_G>mscodee.dll в полный рост импортирует в себя:
Ну, наверное, простейшим примером является SS CLI сиречь Rotor. В нём наглядно показано, каким образом можно абстрагироваться от конкретной платформы.
Здравствуйте, Edvard_Grieg, Вы писали:
E_G>Извините что беспокою с довольно глупыми вопросами НО: E_G>Мне интнересно следующее: E_G>1) Как мелкомягкие будут отказываться от вин32
Все очень просто Просто никто не будет отказываться от WinAPI (кстати откуда дровишки?). WinAPI жил живет и будет жить. Вот то что в следующей ОС — Longhorn часть возможностей будет доступна только через управляемый код — это да, это есть. Но WinAPI никуда не денется
Hello, "Edvard_Grieg" > Извините что беспокою с довольно глупыми вопросами НО: > Мне интнересно следующее: > 1) Как мелкомягкие будут отказываться от вин32, если > mscodee.dll в полный рост импортирует в себя: > Практически все функции kernel32.dll,advapi32.dll ??? > Т.е. не работает в режиме ядра а находится в самом что ненаесть пользовательском режиме , и является лишь надстройкой над kernel32.dll,advapi32.dll.
Считай, что это PAL (Platform Abstraction Level). Основная идея, что кроме них эти функции больше никто импортировать не будет. Для альтернативного примера — можно взять ту-же яву под windows. Думаешь она святым духом файлы на диске создает? Где-то на самом низу используются все теже WinAPI функции...
> Я проанализировал формат CLR PE EXE и пришел к выводу что любое net приложение может > запросто работать как с управляемым так и с неуправляемым кодом????
Это принцип — "каждый сам себе злой буратино". Кто-то может писать код ограничиваясь только .NET возможностями. А кому-то кровь из носу надо напрямую работать с winapi, указателями и наплевать на переносимость.
> Кроме всего прочего мне кажется что мелкомягкие библиотеку Runtime включаемую в проекты MSVC просто перенесли в mscoree.dll. > Как мелкомягкие будут избегать работы в "куче" управляемого кода? Они предоставят интерфейс для работы с кучей(инкапсулировать те самые :HeapFree :: 501 > HeapAlloc :: 495 !kernel32.dll) а сама куча будет выполнятся в mscoree.dll?
Работать с управляемой "кучей" можно только из управляемого кода. runtime устроен таким образом, что никому указатели на объекты в управляемой куче не выдает (так-же как и нельзя извне выделить память в управляемой куче). В итоге про объекты в управляемой куче в .NET можно сказать только то, что они есть, но где будет храниться экземпляр объекта в следующий момент — тут ничего определенного сказать нельзя...
> И еще ведь mscoree.dll будет исполняться в контексте вызвавшего ее процесса а ненаоборот. Какой тогда вообще смысл от этой надстройки. Заранее извиняюсь за глупые вопросы. >
Posted via RSDN NNTP Server 1.9 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, SiAVoL, Вы писали:
E_G>>Извините что беспокою с довольно глупыми вопросами НО: E_G>>Мне интнересно следующее: E_G>>1) Как мелкомягкие будут отказываться от вин32 SAV>Все очень просто Просто никто не будет отказываться от WinAPI (кстати откуда дровишки?). WinAPI жил живет и будет жить. Вот то что в следующей ОС — Longhorn часть возможностей будет доступна только через управляемый код — это да, это есть. Но WinAPI никуда не денется
Но вчем же соль??? Да и вообще как они порежут обращения к WinAPI и сделают их
доступными только через управляемый код если известно что:
[QUOTE]
2.3.1 Import Address Table (IAT)
The IAT is used for one of the following:
To import mscoree.dll (ie: the runtime engine) for the x86 loader thunk
In a mixed managed/unmanaged image, for legacy imports
The IAT burns into the image slots for methods of a fixed size and is therefore not portable between 32 and 64-bit systems. For this reason, it is ideal to use the metadata to import legacy methods and data through the PInvoke feature. For an image using the IAT only to import the runtime, the IAT is completely ignored and therefore not a problem (presumes an OS loader which is CLR-aware).
[/QUOTE]
Невольно заостряется внимание на этом:
[QUOTE]
it is ideal to use the metadata to import legacy methods and data through the PInvoke feature.
[/QUOTE]
В документации далее вообщето говориться о равновозможной работе потоков как
управляемого кода так и неуправляемого кода
Кроме того большинство CLR приложений которые я вытянул с инета,(к сожалению не являюсь счастливым обладателем скоростного проца и не поставил себе MSVC7)
так или иначе упорно импортируют чтонибудь из kernel32.dll совершенно непоглядывая в сторону mscoree.
Да и мне непонятно как будет производиться инкапсуляция графических функций?
Ведь ни user ни gdi не импортируются mscoree. Неповерю что она работает с win2k.sys
напрямую.
SAV>Все очень просто Просто никто не будет отказываться от WinAPI (кстати откуда дровишки?). WinAPI жил живет и будет жить. Вот то что в следующей ОС — Longhorn часть возможностей будет доступна только через управляемый код — это да, это есть. Но WinAPI никуда не денется
Это почему? WinAPI — не есть "винда" (а gnu — это не "юникс" ).
Win32 — это всего лишь платформа, построенная поверх Native API (реализованный в ntdll.dll, который работает поверх ntoskrnl.exe).
Так что выкинуть Win32 — не проблема, по крайней мере, не принципиальная проблема.
Скорее наоборот, в след. системах Win32 будет эмулироваться поверх чего-то другого (для совместимости), а потом отомрет, когда-нить...
SAV>>Все очень просто Просто никто не будет отказываться от WinAPI (кстати откуда дровишки?). WinAPI жил живет и будет жить. Вот то что в следующей ОС — Longhorn часть возможностей будет доступна только через управляемый код — это да, это есть. Но WinAPI никуда не денется
RB>Это почему? WinAPI — не есть "винда" (а gnu — это не "юникс" ). RB>Win32 — это всего лишь платформа, построенная поверх Native API (реализованный в ntdll.dll, который работает поверх ntoskrnl.exe). RB>Так что выкинуть Win32 — не проблема, по крайней мере, не принципиальная проблема.
RB>Скорее наоборот, в след. системах Win32 будет эмулироваться поверх чего-то другого (для совместимости), а потом отомрет, когда-нить...
я согласен с Вами RusBlood все раелизовано в ntoskernel,hal,ntdll,ndis и т.д.
Сменить WinAPI32 лишь дело техники, она в действительности не родные
Вопрос то вот в чем, получается что то самое mscoree.dll лишь переходная заглушка пока в том виде в котором есть? Получается что дальше оно станет чем то более фундаментальным чем сейчас??? Значит будут еще какието огромные изменения?
Особенно интересно изменится ли ядро Longhorn т.е. будет ли отличатся от привычного и мною любимого ntoskrnl? Упорно ходят слухи о том, что Мелкомягкие выкупают ядро FreeBSD я конечно понимаю что звучит смешно но слухи вращаются и вращаются
Здравствуйте, Edvard Grieg, Вы писали:
EG>Вопрос то вот в чем, получается что то самое mscoree.dll лишь переходная заглушка пока в том виде в котором есть? Получается что дальше оно станет чем то более фундаментальным чем сейчас??? Значит будут еще какието огромные изменения?
Думаю, дело идет к этому. Это было бы логично...
EG>Особенно интересно изменится ли ядро Longhorn т.е. будет ли отличатся от привычного и мною любимого ntoskrnl? Упорно ходят слухи о том, что Мелкомягкие выкупают ядро FreeBSD я конечно понимаю что звучит смешно но слухи вращаются и вращаются
Здравствуйте, Edvard Grieg, Вы писали:
EG>Сменить WinAPI32 лишь дело техники, она в действительности не родные
а зачем менять WinAPI на что-то другое? И что значит "в действительности не родные"?
EG>Вопрос то вот в чем, получается что то самое mscoree.dll лишь переходная заглушка пока в том виде в котором есть?
mscoree.dll своего рода слой абстракции от низкоуровневых механизмов типа WinAPI. Наружу она выдает некий интерфейс а реализует его через системные библотеки, будь то WinAPI или UnixAPI (возможно оно и не так называется, не силен в юнихах ).
EG> Получается что дальше оно станет чем то более фундаментальным чем сейчас??? Значит будут еще какието огромные изменения?
все когда-нибудь меняется но о каких фундаментальных и огромных изменениях ты говоришь, мне не очень понятно. ТО что будут появляться все более высокоуровневые библиотеки и интерфейсы — это естественно. В этом направлении все и развивается. Но и от низов никуда не деться, точно так же как никуда не убежать от ассемблера
EG>Особенно интересно изменится ли ядро Longhorn т.е. будет ли отличатся от привычного и мною любимого ntoskrnl?
на сколько я знаю, там будет развитие старого доброго виндового ядра
EG> Упорно ходят слухи о том, что Мелкомягкие выкупают ядро FreeBSD я конечно понимаю что звучит смешно но слухи вращаются и вращаются
я о таких слухах не слыхал И вообще странный какой-то слушок А откуда дровишки?
RB>Думаю, дело идет к этому. Это было бы логично...
Это будет действительно плохо. Потому что я подозреваю что наверняка будут весьма значимые доработки ядра
Но пока разглядывая код RVA EntryPoint увидел довольно интересный вызов:
RvaEntryPoint:
push eax
call esi
похоже что при вызове mscoree.dll происходит некое определение параметра в регистре eax,
для дальнейшей передаче его процедуре адресс которой соответственно должен находиться в esi.
как он туда попадает?
Пока что mscoree.dll это всеголишь заглушка для Win32 API а какже весь этот пафос?
Какже все это величие этого самого нета?
я конечно понимаю что это самое mscoree.dll которое я гдето непойми где скачал далеко не авторитет.
Но и по нему можно судить о многом
Вобщем я думаю что Мелкомягкие пока что реализовали и выдали юзерям только заглушку, а не действительно готовую и работающую систему.
И мне непонятен весь тот восторг с которым все прыгают вокруг этого Net-а которого покачто помоему всеще нет,
как шаманы с бубнами, возможно я ошибаюсь.
И где же все это величие? Где весь тот пафос вокруг этого несчастного NET ?
RB>Ничего не могу сказать...
Дело то в том что никто не может.
Здравствуйте, SiAVoL, Вы писали:
SAV>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Сменить WinAPI32 лишь дело техники, она в действительности не родные SAV>а зачем менять WinAPI на что-то другое? И что значит "в действительности не >родные"?
Про родные API можно прочесть у Марка Руссиновича.
Win32 API всеголишь абстрагирование от родных(Native API) Windows NT.
EG>>Вопрос то вот в чем, получается что то самое mscoree.dll лишь переходная заглушка пока в том виде в котором есть? SAV>mscoree.dll своего рода слой абстракции от низкоуровневых механизмов типа WinAPI. Наружу она выдает некий интерфейс а реализует его через системные библотеки, будь то WinAPI или UnixAPI (возможно оно и не так называется, не силен в юнихах ).
предлагаю обойтись простым словом "заглушка" слой абстрагирования для теперешней нет,
пока слишком серьездное название imho
EG>> Получается что дальше оно станет чем то более фундаментальным чем сейчас??? Значит будут еще какието огромные изменения? SAV>все когда-нибудь меняется но о каких фундаментальных и огромных изменениях ты говоришь, мне не очень понятно. ТО что будут появляться все более высокоуровневые библиотеки и интерфейсы — это естественно. В этом направлении все и развивается. Но и от низов никуда не деться, точно так же как никуда не убежать от ассемблера
Мне кажется нарасщивание слоев неэффективно, в связи с бесполезным использованием
времени процессора равно как и других ресурсов для перехода от слоя к слою.
SAV>на сколько я знаю, там будет развитие старого доброго виндового ядра
Большинство драйверистов не очень в этом уверены
EG>> Упорно ходят слухи о том, что Мелкомягкие выкупают ядро FreeBSD я конечно понимаю что звучит смешно но слухи вращаются и вращаются SAV>я о таких слухах не слыхал И вообще странный какой-то слушок А откуда дровишки?
Да вот за последние несколько месяцев перечитал некое кол-во статей,
где об этом писалось, к сожалению вспомнить это я сейчас не в состоянии.
И еще самое главное:
А кто собственно мешает воспользоваться mscoree.dll из обычного самого что нинаесть стандартного PEEXE WIN32?????
Hinst = Loadlibrary("mscoree32.dll");
GetXMLElement = GetProcAddress(Hinst,"GetXMLElement");
GetXMLElement();
и т.д.
????
я конечно понимаю что я наверное непонимаю о чем говорю,MSVC.NET не установлен
но я подозреваю что можно писать .NET приложения даже на BorlandDelphi 3.0
Да никто не мешает. Более того, все так и происходит.
PE-шник, генерируемый в ".net" — это самый обычный PE-шник, у которого вначале идет загрузка mscoree и передача управления в эту dll. А та уже подгружает ресурсы из PE-шника, читает байт-код и пр. хрень.
Но с точки зрения платформы сейчас исполняемые файлы — те же PE-шники.
Все это переходный период, это описано во всякой литературке, и в будущем, может быть, будет по-другому.
Здравствуйте, rus blood, Вы писали:
RB>Здравствуйте, Edvard Grieg, Вы писали:
RB>Да никто не мешает. Более того, все так и происходит.
RB>PE-шник, генерируемый в ".net" — это самый обычный PE-шник, у которого вначале идет загрузка mscoree и передача управления в эту dll. А та уже подгружает ресурсы из PE-шника, читает байт-код и пр. хрень.
RB>Но с точки зрения платформы сейчас исполняемые файлы — те же PE-шники. RB>Все это переходный период, это описано во всякой литературке, и в будущем, может быть, будет по-другому.
Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут сгенерированы Святым Духом.
Здравствуйте, Edvard Grieg, Вы писали:
EG>И еще самое главное: EG>А кто собственно мешает воспользоваться mscoree.dll из обычного самого что нинаесть стандартного PEEXE WIN32????? EG>но я подозреваю что можно писать .NET приложения даже на BorlandDelphi 3.0
у меня начинает складываться впечатление, что от всего .NETа у вас только mscoree.dll
Здравствуйте, SiAVoL, Вы писали:
SAV>Здравствуйте, Edvard Grieg, Вы писали:
EG>>И еще самое главное: EG>>А кто собственно мешает воспользоваться mscoree.dll из обычного самого что нинаесть стандартного PEEXE WIN32????? EG>>но я подозреваю что можно писать .NET приложения даже на BorlandDelphi 3.0 SAV>у меня начинает складываться впечатление, что от всего .NETа у вас только mscoree.dll
Именно так и есть,т.е. .NET я не устанавливал я выше об этом писал. Просто негде мне его взять,
вот я и поднял доки по clr PE EXE , скачал этот mscoree и начал его ковырять.
Но мне кажется что основа всего этого безобразия mscoree.dll.
Longhorn -поставить негде чтобы расковырять.
Вот и ковыряю то что скачал откудато
OD>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
А вчем проблема их отдельно прилинковать?
Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
Кстати скринсейвер longhorn-a если кто посмотрит самый обычный PEEXE файл обычнее некуда работает под W2K без всякого NET, но тем неменее meta-данные содержит
Здравствуйте, Edvard Grieg, Вы писали:
EG>Именно так и есть,т.е. .NET я не устанавливал я выше об этом писал.
тогда все ясно EG>Просто негде мне его взять, .NET Framework 1.1 .NET Framework 1.1 SDK
а что бы не гадать на кофеной гуще как это все работает, можно слить еще и Rotor — реализация .NET от микросовта в исходниках, в общем скачай будет интересно.
А что бы посмотреть на другие реализации можно зайти на проект Mono, тоже в исходниках. Кстати у них недавно первый релиз был EG>Но мне кажется что основа всего этого безобразия mscoree.dll.
основа то основа, но несколько низкоуровневая EG>Longhorn -поставить негде чтобы расковырять.
для НЕТа его ставить совсем необязательно. Рог он где-то там за горизонтом, а дотНЕТ уже здесь с нами
Здравствуйте, Edvard Grieg, Вы писали:
EG>Здравствуйте, SiAVoL, Вы писали:
SAV>>Здравствуйте, Edvard Grieg, Вы писали:
EG>>>И еще самое главное: EG>>>А кто собственно мешает воспользоваться mscoree.dll из обычного самого что нинаесть стандартного PEEXE WIN32????? EG>>>но я подозреваю что можно писать .NET приложения даже на BorlandDelphi 3.0 SAV>>у меня начинает складываться впечатление, что от всего .NETа у вас только mscoree.dll EG>Именно так и есть,т.е. .NET я не устанавливал я выше об этом писал. Просто негде мне его взять, EG>вот я и поднял доки по clr PE EXE , скачал этот mscoree и начал его ковырять. EG>Но мне кажется что основа всего этого безобразия mscoree.dll. EG>Longhorn -поставить негде чтобы расковырять. EG>Вот и ковыряю то что скачал откудато
Ну... Еслм судить о курице по тому, что в столовой можно находишь в супе, то получится, что курица — это такая длинная-длинная мохнатая змея. В данном случае, по-моему, аналогия вполне уместна. Вы судите о продукте, даже не взглянув на него.
Кроме того, обратите внимание, что Вы постоянно употребляешь слова "не понимаю", "кажется" и т.д. Так вот — судя по Вашим сообщениям, Вы действительно не понимаете (даже приблизительно), о чём идёт речь, и Вам многое кажется. Наверное, неплохо было бы и "поиграться" с продуктом, а потом делать какие-то выводы (мол, "безобразие"... ). Получается как в известной фразе: "Я Солженицына не читал, но знаю, что он — подлец".
Просто никто не будет отказываться от WinAPI (кстати откуда дровишки?). WinAPI жил живет и будет жить. Вот то что в следующей ОС — Longhorn часть возможностей будет доступна только через управляемый код — это да, это есть. Но WinAPI никуда не денется
но о каких фундаментальных и огромных изменениях ты говоришь, мне не очень понятно. ТО что будут появляться все более высокоуровневые библиотеки и интерфейсы — это естественно. В этом направлении все и развивается. Но и от низов никуда не деться, точно так же как никуда не убежать от ассемблера 
А откуда дровишки?
