Здравствуйте, 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>Вот и ковыряю то что скачал откудато
Ну... Еслм судить о курице по тому, что в столовой можно находишь в супе, то получится, что курица — это такая длинная-длинная мохнатая змея. В данном случае, по-моему, аналогия вполне уместна. Вы судите о продукте, даже не взглянув на него.
Кроме того, обратите внимание, что Вы постоянно употребляешь слова "не понимаю", "кажется" и т.д. Так вот — судя по Вашим сообщениям, Вы действительно не понимаете (даже приблизительно), о чём идёт речь, и Вам многое кажется. Наверное, неплохо было бы и "поиграться" с продуктом, а потом делать какие-то выводы (мол, "безобразие"... ). Получается как в известной фразе: "Я Солженицына не читал, но знаю, что он — подлец".
RB>Думаю, дело идет к этому. Это было бы логично...
Это будет действительно плохо. Потому что я подозреваю что наверняка будут весьма значимые доработки ядра
Но пока разглядывая код RVA EntryPoint увидел довольно интересный вызов:
RvaEntryPoint:
push eax
call esi
похоже что при вызове mscoree.dll происходит некое определение параметра в регистре eax,
для дальнейшей передаче его процедуре адресс которой соответственно должен находиться в esi.
как он туда попадает?
Пока что mscoree.dll это всеголишь заглушка для Win32 API а какже весь этот пафос?
Какже все это величие этого самого нета?
я конечно понимаю что это самое mscoree.dll которое я гдето непойми где скачал далеко не авторитет.
Но и по нему можно судить о многом
Вобщем я думаю что Мелкомягкие пока что реализовали и выдали юзерям только заглушку, а не действительно готовую и работающую систему.
И мне непонятен весь тот восторг с которым все прыгают вокруг этого Net-а которого покачто помоему всеще нет,
как шаманы с бубнами, возможно я ошибаюсь.
И где же все это величие? Где весь тот пафос вокруг этого несчастного NET ?
RB>Ничего не могу сказать...
Дело то в том что никто не может.
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
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Что меня интересует: EG>1) Исчезнут ли win32 api с появлением .net. EG>2) Изменится ли объкт ядра "process" EG>3) что станет с system и idle EG>4) Зачем .NET испозьзует win32 , а не к примеру Native API. EG>Ответ на эти вопросы для меня многое бы прояснил.
Думаю, Вы делаете ту же ошибку, какую когда-то сделал я, а именно — роетесь в мелочах, не понимая даже предназначения .NET'а. Другими словами, за деревьями не видите леса. Поэтому позволю себе дать Вам совет — постарайтесь всё же понять идеологию .NET в целом. Просто почувствовать её. Многое, наверное, станет на свои места.
Здравствуйте, 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>Пока что mscoree.dll это всеголишь заглушка для Win32 API а какже весь этот пафос? EG>Какже все это величие этого самого нета? EG>я конечно понимаю что это самое mscoree.dll которое я гдето непойми где скачал далеко не авторитет. EG>Но и по нему можно судить о многом
EG>Вобщем я думаю что Мелкомягкие пока что реализовали и выдали юзерям только заглушку, а не действительно готовую и работающую систему. EG>И мне непонятен весь тот восторг с которым все прыгают вокруг этого Net-а которого покачто помоему всеще нет, EG>как шаманы с бубнами, возможно я ошибаюсь.
EG>И где же все это величие? Где весь тот пафос вокруг этого несчастного NET ?
Я плякаль. Давай я тебе еще экзешник от Ворда вышлю, а ты нам напишешь о том, что это за продукт...
Слабо скачать дотнет и попробовать написать программу?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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>И еще самое главное: EG>А кто собственно мешает воспользоваться mscoree.dll из обычного самого что нинаесть стандартного PEEXE WIN32????? EG>но я подозреваю что можно писать .NET приложения даже на BorlandDelphi 3.0
у меня начинает складываться впечатление, что от всего .NETа у вас только mscoree.dll
Здравствуйте, Edvard Grieg, Вы писали:
OD>>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
EG>А вчем проблема их отдельно прилинковать? EG>Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
Н-да... Значит, по-Вашему, метаданные — это XML? Тяжело... А чем они линкуются, не подскажете?
EG>Кстати скринсейвер longhorn-a если кто посмотрит самый обычный PEEXE файл обычнее некуда работает под W2K без всякого NET, но тем неменее meta-данные содержит
Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
Здравствуйте, Edvard_Grieg, Вы писали:
E_G>Извините что беспокою с довольно глупыми вопросами НО: E_G>Мне интнересно следующее: E_G>1) Как мелкомягкие будут отказываться от вин32, если E_G>mscodee.dll в полный рост импортирует в себя:
-- skip -- E_G>Практически все функции kernel32.dll,advapi32.dll ??? E_G>Т.е. не работает в режиме ядра а находится в самом что ненаесть пользовательском режиме , и является лишь надстройкой над kernel32.dll,advapi32.dll. E_G>Я проанализировал формат CLR PE EXE и пришел к выводу что любое net приложение может E_G>запросто работать как с управляемым так и с неуправляемым кодом???? E_G>Кроме всего прочего мне кажется что мелкомягкие библиотеку Runtime включаемую в проекты MSVC просто перенесли в mscoree.dll. E_G>Как мелкомягкие будут избегать работы в "куче" управляемого кода? Они предоставят интерфейс для работы с кучей(инкапсулировать те самые :HeapFree :: 501 E_G> HeapAlloc :: 495 !kernel32.dll) а сама куча будет выполнятся в mscoree.dll? E_G>И еще ведь mscoree.dll будет исполняться в контексте вызвавшего ее процесса а ненаоборот. Какой тогда вообще смысл от этой надстройки. Заранее извиняюсь за глупые вопросы.
E_G>with best regards Edvard Grieg http://www.angelfire.com/rpg2/e_grig
Сразу скажу, что я не претендую на истину, но вот мое ИМХО:
Microsoft .NET является по сути платформенно-независимой средой исполнения. Т.е. программа, написанная под .NET может исполняться на любой системе, где стоит .NET, и это может быть не WIN-система. Если конечно, программа не использует платформенно-зависимые средства (такие как непосредственный импорт или обращение к ситемным библиотекам). Ближайший аналог — JAVA.
Программа для .NET компилируется во внутренний язык (IL) и при запуске компилируется в исполняемый код средой исполнения, что обеспечивает такие возможности как:
кроссплатформенная переносимость кода
оптимизация средой исполнения
вызокая безопасность управляемого кода
и пр.
Естественно, что такая исполняющая среда должна иметь внутри себя интерфейсы к системному API или реализовывать свои Native API. На данный момент Microsoft решили упростить себе жизнь реализовав оболочку для WIN32 API. По моему мнению тут сыграло роль то, что переход сразу к новому API был бы слишком сложен для программистов, т.к. большинству проще воспользоваться чем-то похожим на привычное, чем совсем новым.
Насколько я понимаю, в Longhorn системное API будет новым и для совместимости будет сохранен WIN32 API, который станет оболочкой над системным API Longhorn. Соответственно в .NET системные библиотеки будут реализованы на основе системного API, а не WIN32.
TK>Работать с управляемой "кучей" можно только из управляемого кода. runtime устроен TK>таким образом, что никому указатели на объекты в управляемой куче не выдает (так-TK>же как и нельзя извне выделить память в управляемой куче). В итоге про объекты в TK>управляемой куче в .NET можно сказать только то, что они есть, но где будет TK>храниться экземпляр объекта в следующий момент — тут ничего определенного сказать TK>нельзя...
А чтоже станет с дровами??? Будут ли дрова от WinXP,W2k переносимы на Longhorn или какбы точнее выразиться на платформу где уже будет легален только .NET.
Что станет с Native API?
я просто помню заявление мелкомягких, что правильно написанный драйвер использующий
_только_ ресурсы hal для обращению к аппаратным ресурсам(без ассемблерных вставок),
будет переносим на различные другие платформы.
С учетом существования только managed code, у меня создается впечатление что мелкомягкие стремятся к unix модели , когда есть микроядро оно в кольце 0,
а все остальное в том числе и дрова, в кольце 3.
Неужели они стремятся к этому?
Опятьже все больше и больше Native API документируется мелкомягкими, а сколько я их(мелкомягких) помню они начинают документировать особенно выжные возможности
операционки перед ее моральной смертью.
Вспомним даже не Native API и не Win32 а интерфейс Protected Storage базирующийся на
IUncknown , они опубликовали его где-то в феврале в msdn.
Здравствуйте, Nuald, Вы писали:
N>Я там ничего такого не нашел. Я конечно понимаю, что WinFX написан как .NET сборки, и на неуправляемом коде будет тяжелее писать, но все-таки где написано, что некоторая функциональность доступна только из управляемого кода??
The "Longhorn" graphics rendering layer, called the Media Integration Layer (MIL), provides new graphics and animation features previously provided by the application of specialized libraries. "Avalon" applications use the MIL in place of previous Microsoft® Windows® graphics systems like Windows Graphics Device Interface (GDI) and Windows GDI+. Although developers who want to make use of the full range of "Avalon" features must write managed applications entirely with the "Avalon" application programming interfaces (APIs), the MIL supports limited interoperation with GDI content.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Про родные API можно прочесть у Марка Руссиновича. EG>Win32 API всеголишь абстрагирование от родных(Native API) Windows NT.
Вот и подумай если МС не отказался даже от Win16 и POSIX, то зачем им отказываться от Win32, да еще и эмулировать его? Эти домыслы слишком часто появляется на форумах, чтобы он рождался в головах разных людей. Тому козлу который неразобравшись ляпнул данную глупость в прессе нужно настучать линейкой по пальцам.
EG>предлагаю обойтись простым словом "заглушка" слой абстрагирования для теперешней нет, EG>пока слишком серьездное название imho
Количество функций в дотнете на два порядка превышает оное в Вынь32. Так что в пору считать Вынь32 заглушкой перед железом.
EG>Мне кажется нарасщивание слоев неэффективно, в связи с бесполезным использованием EG>времени процессора равно как и других ресурсов для перехода от слоя к слою.
Кроме эффективности есть еще такие вещи как совместимость и универсальность. МС делает все не абы как. Там все продумывается и тестируется. Слои режут там где это меньше всего влияет на производительность. В итоге получается, что низкий уровень уходит в нэйтив-код, а высокий в дотнет. Так что все ОК.
EG>Большинство драйверистов не очень в этом уверены
И что мешает им скачать ЛХ и поставить на него, например, драйвер от Nvidia?
EG>Да вот за последние несколько месяцев перечитал некое кол-во статей, EG>где об этом писалось, к сожалению вспомнить это я сейчас не в состоянии.
Ну, так дай ссылку. А то действительно сплетня не стоящая обсуждения.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Извините если Вас обидел своим незнанием EG>Ваша статья просто замечательна EG>Большое спасибо за статью и за программу EG>Теперь весь этот топик считаю просто ненужным EG>Желаю Вам еще больших успехов
Боюсь, что ты так и не понял о том, что тебе сказал ОлдДино несколько постов назад.
Попробую повторить... Разбираясь с дотнетом на таком низком уровене не вникая в его концепцию и идеологию ты делаешь ОГРОМНУЮ ошибку. Дотнет — это не формат ПЕ и т.п. — это стройная концепция. Для ее понимания вообще не обязательно знать о наличии разных мскорлибов и т.п.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Раз уж заговорили о низком уровне....
Ну пытаются .NET поближе к ядру подтянуть, WinAPI заменить итд. Но насколько близко в Longhorn он к ядру будет интересно.
Сейчас у .NET не то чтобы статус, скажем, скрипта в веб браузере. Но все же где то на этом уровне — просто поверхностная оболочка какая то.
А разница большая насколько он близок к ядру.
Будет ли когда нибудь централизованое управление памятью. Что имеем сейчас — один .NET процесс может с легкой руки сотню другую мегабайт ОЗУ мусора держать. Система может попасть в глубокий своп из-за нехватки памяти. А мусорщиков в .NET процессе никто пинать сейчас не собирается, они по своему усмотрению действуют.
Другими словами мусор в .NET процессе не является мусором для всей системы.
Реально ли уменьшить занимаемую память под .NET процессы хотябы до 10 мег.
Что сейчас происходит в памяти если запустить 20-30 .NET процессов. Оттяпают они судя по всему 1 гиг памяти. И начнется брутальный свопинг. А если в эту память как-то заглянуть то судя по всему из этого 1 гига, штук 800-900 мег будет просто повторяющиеся копипи одних и тех же кусков продублированных. Вот хорошо ли это . А ничего преступного вроде в этом нет чтобы исполнялось 20-30 процессов в многозадачной системе.
Вот когда винда научится держать 30 .NET процессов, не зашкаливая в потреблении памяти за 500 мег. Тогда только можно будет говорить о замене WinAPI.
Имеется ведь ввиду пороцессы практически без своего функционала, только стандартные фичи из .NET использующие.
Здравствуйте, Edvard Grieg, Вы писали:
EG>ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители... SAV>>два года ( + год-два на распространение ОС) у регионов есть что бы SAV>приобрести /что-то вроде P-IV. Так что все нормально EG>У регионов еще 80286 несписанные стоят и пашут
Можешь мне не рассказывать, у меня в профайле значится Архангельск. Так вот, это правда Мой продукт (.NET) несмотря на минимальные требования, успешно используют на P-133 64Mb. И ничего, радуются жизни (только вот грузится долго, прихошлось приписать к обновлялке опциональнцю функцию обработки сборок ngen`ом, стало лучше). Так что не все так плохо.
Здравствуйте, Nuald, Вы писали:
VD>>Все универсальное убого. Так что тут заморчиваться не нужно. Все равно ты не сможешь обеспечить подержки всех фич всех ОС. Так что или выбирай Яву (возможно дотнет с Моно) или С/С++ и забивай на фичи ОС. Опять таки сможешь привинчивать ОС-специфичные фичи вручную.
N(например, Silent Hill <версия>)...
Потому эта игра и не является Far Cry-ем.
VD>>Каждая новая ОС будет жрать все больше и бльше ресурсов. По крайней мере до глобального рефакторинга или до переписывания с нуля. Это закон. Тут ничего не поделаешь. Только дотнет тут совершенно не причем. В том же ЛХ основную память сжирает MSSQL.
N>Никогда такого не слышал... Помню еще OS/2 работала достаточно хорошо на слабой тачке, когда для винды нужно было для тех же задач куда больше ресурсов...
Агащасблин. 95-ые была куда производительнее на том же железе чем полуось. Эти сказки рассказывай тем кто сам не выбросил полуось после выхода 95-ых и NT 3.5.
N>И причем MSSQL и рог??
Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL.
N>После этого точно лучше вообще отказаться от них — не надо нам таких фич, не хватало чтобы еще пользовательская машина стала источников неимоверных дыр (то, что код управляемый не означает что в нем не может быть переполнение буфера и т.п.)...
"Вам" то может и следует. Вот только эти вопросы стоит осбуждать в священных войнах. А для большей честности стоит еще и пересесть на какой-нить ликух.
N>ИМХО вы не работали в госструктурах,
Я себе не враг.
N>или в организациях, которые еще живут по совковскому принципу — "Работает, так и ладно, незачем тратить деньги на всякую лабуду"...
Ну, и будт работаь пока техника не сдохнет. А сдохнет, купят новую с ЛХ или еще чем нибудь поновее.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Это далеко не сказки к сожалению, может ктото и обгоняет европпу но у нас однозначно EG>45% парка 80x286 80x386.
Мдя... как-то совсем у вас печально
Тогда о .NET`е можно даже и не думать, а вот
ДОС! Черной пеленой
Экран заполнил чистый дос.
Мышь! потеряла форму,
Стала вдруг квадратной мышь.
Я разбил окно,
95-е масдайное окно.
И поставил Дос ....
EG>Вобщем я думаю что Мелкомягкие пока что реализовали и выдали юзерям только заглушку, а не действительно готовую и работающую систему.
Может и заглушку, но работающую. Почему это важно — далее.
EG>И мне непонятен весь тот восторг с которым все прыгают вокруг этого Net-а которого покачто помоему всеще нет, EG>как шаманы с бубнами, возможно я ошибаюсь.
По-моему, да.
EG>И где же все это величие? Где весь тот пафос вокруг этого несчастного NET ?
Если не брать новые технологии (remoting, web-service etc.), то вот навскидку пара пунктов для пафоса:
1. решение вопроса с версиями: а) dll hell, б) COM hell (старые версии в новых COM-ах)
2. многоплатформенность
Про п.2 подробнее. Код в .net не win32 и никогда не будет win32. В win32 его транслирует загрузчик из framework-a. Это значит, что на другом проце (с другим порядком следвания байт) или на другой ОС этот код может исполняться, если там есть соответствующий framework. Кстати, framework для Linux уже пишут . Когда его напишут, одну и ту же программу можно будет без изменений и перекомпиляций пускать как на windows, так и на Linux. Как думаешь, это достойно пафоса?
Ну а то что пока везде одни заглушки — фиг с ними. Главное — .net есть, на него переходят программеры, с ним они учатся работать. Потом внутренности framework-a можно сменить, прогу переписывать не надо.
Кстати, для тех, кто захочет сказать что под windows многоплатформенность — не актуально. Нет, актуально, т.к. этих самих windows-ов уже наклепали столько, что win32 себя на разных windows ведет себя по-разному (вспомните win95 и NT). .Net призван быть новым стандартом, в котором все функции работают одинаково.
Здравствуйте, 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 никуда не денется
Здравствуйте, 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
напрямую.
Здравствуйте, 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 я конечно понимаю что звучит смешно но слухи вращаются и вращаются
я о таких слухах не слыхал И вообще странный какой-то слушок А откуда дровишки?
Здравствуйте, 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. А, скажем, метаданные будут сгенерированы Святым Духом.
Здравствуйте, 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-данные содержит
RB>Да никто не мешает. Более того, все так и происходит.
RB>PE-шник, генерируемый в ".net" — это самый обычный PE-шник, у которого вначале RB>идет загрузка mscoree и передача управления в эту dll. А та уже подгружает RB>ресурсы из PE-шника, читает байт-код и пр. хрень.
Но это я и так понял:
А гдеж тогда храниться SEH,PEB исполнимого файла .NET?
У обычного PE -процесса fs:[xxx] , там и пеб и цех.
Загрузчик все будет интерпретировать как и раньше?
И еще а как заполняется для .NET PEEXE Import Adress Table загрузчиком или
она уже будет заполнена? Или и так и эдак возможно как и раньше?
Здравствуйте, SiAVoL, Вы писали:
SAV>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Именно так и есть,т.е. .NET я не устанавливал я выше об этом писал. SAV>тогда все ясно EG>>Просто негде мне его взять, SAV>.NET Framework 1.1 SAV>.NET Framework 1.1 SDK SAV>а что бы не гадать на кофеной гуще как это все работает, можно слить еще и Rotor — реализация .NET от микросовта в исходниках, в общем скачай будет интересно. SAV>А что бы посмотреть на другие реализации можно зайти на проект Mono, тоже в исходниках. Кстати у них недавно первый релиз был EG>>Но мне кажется что основа всего этого безобразия mscoree.dll. SAV>основа то основа, но несколько низкоуровневая EG>>Longhorn -поставить негде чтобы расковырять. SAV>для НЕТа его ставить совсем необязательно. Рог он где-то там за горизонтом, а дотНЕТ уже здесь с нами
Большое спасибо
Попробую у когонибудь с хорошим каналом это вытянуть
OD>Кроме того, обратите внимание, что Вы постоянно употребляешь слова "не OD>понимаю", "кажется" и т.д. Так вот — судя по Вашим сообщениям, Вы действительно OD>не понимаете (даже приблизительно), о чём идёт речь, и Вам многое кажется. OD>Наверное, неплохо было бы и "поиграться" с продуктом, а потом делать какие-то OD>выводы (мол, "безобразие"... ). Получается как в известной фразе: "Я Солженицына OD>не читал, но знаю, что он — подлец".
Дык я сюда и зашел чтобы поспрашивать насчет всего этого "безобразия" и понять как это устроено хоть приблизительно. Если к примеру комуто попадется ntoskrnl.exe и hal.dll я предполагаю что этот кто-то сможет сделать выводы относительно win2k в целом,и эти выводы небудут той самой "волосатой змеей".
Что меня интересует:
1) Исчезнут ли win32 api с появлением .net.
2) Изменится ли объкт ядра "process"
3) что станет с system и idle
4) Зачем .NET испозьзует win32 , а не к примеру Native API.
Ответ на эти вопросы для меня многое бы прояснил.
Здравствуйте, OldDino, Вы писали:
OD>Здравствуйте, Edvard Grieg, Вы писали:
OD>>>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
EG>>А вчем проблема их отдельно прилинковать? EG>>Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
OD>Н-да... Значит, по-Вашему, метаданные — это XML? Тяжело... А чем они линкуются, не подскажете?
Линкер можно и самому написать, впрочем и собрать PEEXE.
EG>>Кстати скринсейвер longhorn-a если кто посмотрит самый обычный PEEXE файл обычнее некуда работает под W2K без всякого NET, но тем неменее meta-данные содержит
OD>Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
Это было не заявление а вопрос вообщето.
я повторюсь что не експерт в .net просто зашел поспрошать.
Но из под dosa как впрочем из под чего угодно можно скомпилировать PEEXE Win32 .
я не заявлял что без .net приложения .net запустяться, я предполагаю что можно создать приложение
на основе обычного PEEXE которое сможет полноценно работать с .NET.
OD>>>>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
EG>>>А вчем проблема их отдельно прилинковать? EG>>>Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
OD>>Н-да... Значит, по-Вашему, метаданные — это XML? Тяжело... А чем они линкуются, не подскажете? EG>Линкер можно и самому написать, впрочем и собрать PEEXE.
OD>Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
Удивительно если бы я эту чушь не нес
Посмотрите название темы, я кажется спрашивал что такое dot.net это значит что я имею весьма слабое об этом представление.
Честно говоря неожидал такой агрессии в свой адресс.
OD>Всё. Наповал! Замолкаю.
я конечно понимаю что новички всегда всех смешат но
Описать секции кода, данных и т.д. соответствующими структурами,
Описать Optional Header со всеми причиндалами.
Заполнить LookUp Table, и т.д.
вот пример того как можно прочитать PEEXE структуры,
ypedef struct _IMPORT_LOOKUP
{
WORD HINT;
char HintName[MAX_PATH];
}IMPORT_LOOKUP, *PIMPORTLOOKUP;
typedef struct _DOS_HEADER { // DOS .EXE çàãîëîâîê
WORD e_magic; // ìàãè÷åñêîå ÷èñëî
WORD e_cblp; // êîëè÷åñòâî áàéò íà ïîñëåäíåé ñòðàíèöå ôàéëà
WORD e_cp; // êîëè÷åñòâî ñòðàíèö â ôàéëå
WORD e_crlc; // Relocations
WORD e_cparhdr; // ðàçìåð çàãîëîâêà â ïàðàãðàôàõ
WORD e_minalloc; // Minimum extra paragraphs needed
WORD e_maxalloc; // Maximum extra paragraphs needed
WORD e_ss; // íà÷àëüíîå ( îòíîñèòåëüíîå ) çíà÷åíèå ðåãèñòðà SS
WORD e_sp; // íà÷àëüíîå çíà÷åíèå ðåãèñòðà SP
WORD e_csum; // êîíòðîëüíàÿ ñóììà
WORD e_ip; // íà÷àëüíîå çíà÷åíèå ðåãèñòðà IP
WORD e_cs; // íà÷àëüíîå ( îòíîñèòåëüíîå ) çíà÷åíèå ðåãèñòðà CS
WORD e_lfarlc; // àäðåñ â ôàéëå íà òàáëèöó ïåðåàäðåñàöèè
WORD e_ovno; // êîëè÷åñòâî îâåðëååâ
WORD e_res[4]; // Çàðåçåðâèðîâàíî
WORD e_oemid; // OEM identifier (for e_oeminfo)
WORD e_oeminfo; // OEM information; e_oemid specific
WORD e_res2[10]; // Çàðåçåðâèðîâàíî
DWORD e_lfanew; // àäðåñ â ôàéëå íîâîãî .exe çàãîëîâêà
} DOS_HEADER, *PDOS_HEADER;
typedef struct _OBJECT_ENTRY
{
char Object_Name[8];
union {DWORD PhisicalAddress;
DWORD VirtualSize;
}Misc;
DWORD VirtualAddress;
DWORD SizeOfRawData;
DWORD PointerToRawData;
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics;
}OBJECT_ENTRY , *POBJECT_ENTRY;
typedef struct _IMPORT_DIRECTORY_ENTRY
{
DWORD ImportLookUp;
DWORD TimeDateStamp;
DWORD ForwardChain;
DWORD NameRVA;
DWORD AddressTableRVA;
}IMPORT_DIRECTORY_ENTRY , *PIMPORT_DIRECTORY_ENTRY;
typedef struct _PEEXE_header
{
DWORD PE_IDENTIFICATOR;
WORD Machine ; // 4c 01 ; i386
WORD NumberOfSections ; // 00 00 00 00 ; who cares?
DWORD DateTimeStamp;
DWORD PointerToSymbolTable ; // 00 00 00 00 ; unused
DWORD NumberOfSymbols ; // 00 00 00 00 ; unused
WORD SizeOfOptionalHeader ; // e0 00 ; constant
WORD Characteristics ; // 02 01 ; executable on 32-bit-machine
WORD Magic ; //0b 01 ; constant
BYTE MajorLinkerVersion; //00 ; I'm version 0.0 :-)
BYTE MinorLinkerVersion; //00 ;
DWORD SizeOfCode ; //20 00 00 00 ; 32 bytes of code
DWORD SizeOfInitializedData ; //?? ?? ?? ?? ; yet to find out
DWORD SizeOfUninitializedData; //00 00 00 00 ; we don't have a BSS
DWORD AddressOfEntryPoint ; //?? ?? ?? ?? ; yet to find out
DWORD BaseOfCode ; //?? ?? ?? ?? ; yet to find out
DWORD BaseOfData ; //?? ?? ?? ?? ; yet to find out
DWORD ImageBase ; //00 00 10 00 ; 1 MB, chosen arbitrarily
DWORD SectionAlignment ; //20 00 00 00 ; 32-bytes-alignment
DWORD FileAlignment ; //20 00 00 00 ; 32-bytes-alignment
WORD MajorOperatingSystemVersion ; //04 00 ; NT 4.0
WORD MinorOperatingSystemVersion ; //00 00 ;
WORD MajorImageVersion ; //00 00 ; version 0.0
WORD MinorImageVersion ; // 00 00 ;
WORD MajorSubsystemVersion ; // 04 00 ; Win32 4.0
WORD MinorSubsystemVersion ; // 00 00 ;
DWORD Win32VersionValue ; // 00 00 00 00 ; unused?
DWORD SizeOfImage ; // ?? ?? ?? ?? ; yet to find out
DWORD SizeOfHeaders ; // ?? ?? ?? ?? ; yet to find out
DWORD CheckSum ; // 00 00 00 00 ; not used for non-drivers
WORD Subsystem ; // 03 00 ; Win32 console
WORD DllCharacteristics ; // 00 00 ; unused (not a DLL)
DWORD SizeOfStackReserve ; // 00 00 10 00 ; 1 MB stack
DWORD SizeOfStackCommit ; // 00 10 00 00 ; 4 KB to start with
DWORD SizeOfHeapReserve ; // 00 00 10 00 ; 1 MB heap
DWORD SizeOfHeapCommit ; // 00 10 00 00 ; 4 KB to start with
DWORD LoaderFlags ; // 00 00 00 00 ; unknown
DWORD NumberOfRvaAndSizes ; // 10 00 00 00 ; constant
DWORD ExportTableRVA ;
DWORD ExportTableRVASize ;
DWORD ImportTableRVA ;
DWORD ImportTableRVASize ;
DWORD ResourceTableRVA ;
DWORD ResourceTableRVASize ;
DWORD ExceptionTableRVA ;
DWORD ExceptionTableRVASize ;
DWORD SecurityRVA ;
DWORD SecurityRVASize ;
DWORD FixUPRva ;
DWORD FixUPRVASize ;
DWORD DebugTableRVA ;
DWORD DebugTableSize ;
DWORD ImageDescriptionRVA ;
DWORD ImageDescriptionSize ;
DWORD MachineSpecificRVA ;
DWORD MachineDataSize ;
DWORD TlsRva ;
DWORD TlsSize ;
DWORD LoadConfigRVA ;
DWORD ConfigSize ;
BYTE RESERVED0[8] ;
DWORD IATRVA ;
DWORD IATSize ;
BYTE RESERVED1[8] ;
BYTE RESERVED2[8] ;
BYTE RESERVED3[8] ;
}PEHeader, *PPEHeader;
int main(int argc, char* argv[])
{
int LibCount =0;
IMPORT_LOOKUP il;
DOS_HEADER ImageDos;
char LibName[MAX_PATH];
unsigned int ImportCount = 0;
int i = 0;
DWORD Pe;
FILE *f;
PEHeader hpe;
int offset_pe = 0;
int step_next = 0;
ZeroMemory(&Pe,2);
f = fopen(argv[1],"r");
fseek(f,0,SEEK_SET);
fread(&ImageDos,sizeof(DOS_HEADER),1,f);
fseek(f,0,SEEK_SET);
fseek(f,ImageDos.e_lfanew,SEEK_SET);
fread(&hpe,sizeof(PEHeader),1,f);
unsigned long CounterSections = ImageDos.e_lfanew+sizeof(PEHeader);
POBJECT_ENTRY obj_sections = new OBJECT_ENTRY [hpe.NumberOfSections];
ZeroMemory(obj_sections,sizeof(OBJECT_ENTRY)*hpe.NumberOfSections);
for (i=0;i<=hpe.NumberOfSections;i++)
{
fseek(f,0,SEEK_SET);
fseek(f,CounterSections,SEEK_SET);
fread(&obj_sections[i],sizeof(OBJECT_ENTRY),1,f);
CounterSections = CounterSections + sizeof(OBJECT_ENTRY);
}
printf("::Sections Count::\n");
printf("%d\n",hpe.NumberOfSections);
printf("::Sections Names::\n");
for (i=0;i<=hpe.NumberOfSections-1;i++)printf("%s\n",obj_sections[i].Object_Name);
fseek(f,0,SEEK_SET);
fseek(f,hpe.ImportTableRVA,SEEK_SET);
ImportCount = hpe.ImportTableRVASize/sizeof(IMPORT_DIRECTORY_ENTRY);
IMPORT_DIRECTORY_ENTRY *ide = new IMPORT_DIRECTORY_ENTRY[ImportCount] ;
ZeroMemory(ide,hpe.ImportTableRVASize);
fread(ide,hpe.ImportTableRVASize,1,f);
printf("::Library list::\n");
for (i=0;i<=ImportCount-1;i++)
{
if (ide[i].NameRVA)
{
++LibCount;
fseek(f,0,SEEK_SET);
fseek(f,ide[i].NameRVA,SEEK_SET);
fread(&LibName,MAX_PATH,1,f);
printf("%s\n",LibName);
printf("import address table:%d\n",ide[i].AddressTableRVA);
}
}
printf("::Import LookUp ::\n");
DWORD *Addr_Ptr =new DWORD[LibCount];
ZeroMemory(Addr_Ptr,sizeof(DWORD) * LibCount);
for (i=0;i<=LibCount - 1;i++)
{
fseek(f,0,SEEK_SET);
fseek(f,ide[i].ImportLookUp,SEEK_SET);
DWORD Counter_Ptr = ide[i].ImportLookUp;
do{
fseek(f,0,SEEK_SET);
fseek(f,Counter_Ptr,SEEK_SET);
fread(&Addr_Ptr[i],sizeof(DWORD),1,f);
fseek(f,Addr_Ptr[i],SEEK_SET);
ZeroMemory(&il,sizeof(IMPORT_LOOKUP));
fread(&il,sizeof(IMPORT_LOOKUP),1,f);
Counter_Ptr = Counter_Ptr + sizeof(DWORD);
printf("%s :: %d\n ",il.HintName,il.HINT);
}
while (Addr_Ptr[i]);
}
fclose(f);
с помощью этого примитива можно запросто считать OptionalHeader mscode.dll и т.д.
Откомпилировать или слинковать секции и куски можно где угодно, лишь бы компилятор был.
Все что можно прочитать можно и записать.Другое дело что приложение откомпилированное под DOS-oм (для примера) но предназначенное для W2k нельзя будет исполнить и отладить.Но откомпилировать можно.
Здравствуйте, OldDino, Вы писали:
OD>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Что меня интересует: EG>>1) Исчезнут ли win32 api с появлением .net. EG>>2) Изменится ли объкт ядра "process" EG>>3) что станет с system и idle EG>>4) Зачем .NET испозьзует win32 , а не к примеру Native API. EG>>Ответ на эти вопросы для меня многое бы прояснил.
OD>Думаю, Вы делаете ту же ошибку, какую когда-то сделал я, а именно — роетесь в мелочах, не понимая даже предназначения .NET'а. Другими словами, за деревьями не видите леса. Поэтому позволю себе дать Вам совет — постарайтесь всё же понять идеологию .NET в целом. Просто почувствовать её. Многое, наверное, станет на свои места.
Это я и так буду делать. В мелочах роюсь. Всегда. Привычка такая. Просто думаю что в мелочах всегда скрывается чтото важное. Есть ла в нете какиенибудь описания .NET на русском языке? Описания clr pe exe на русском,
самой архитектуры? Есть ли disassembler-ы? Отладчики?
EG>я конечно понимаю что новички всегда всех смешат но EG>Описать секции кода, данных и т.д. соответствующими структурами, EG>Описать Optional Header со всеми причиндалами. EG>Заполнить LookUp Table, и т.д. EG>вот пример того как можно прочитать PEEXE структуры,
EG>с помощью этого примитива можно запросто считать OptionalHeader mscode.dll и т.д. EG>Откомпилировать или слинковать секции и куски можно где угодно, лишь бы компилятор был. EG>Все что можно прочитать можно и записать.Другое дело что приложение откомпилированное под DOS-oм (для примера) но предназначенное для W2k нельзя будет исполнить и отладить.Но откомпилировать можно.
Ну, здесь ты меня точно насмешил. Я тебе уже сбросил линк на свою статью. Посмотри заодно и программу к ней...
OD>Ну, здесь ты меня точно насмешил. Я тебе уже сбросил линк на свою статью. OD>Посмотри заодно и программу к ней...
Спасибо очень классная статья
Действительно классная
А сразу нельзя было ее кинуть?
OD>Ну, здесь ты меня точно насмешил. Я тебе уже сбросил линк на свою статью. OD>Посмотри заодно и программу к ней...
Извините если Вас обидел своим незнанием
Ваша статья просто замечательна
Большое спасибо за статью и за программу
Теперь весь этот топик считаю просто ненужным
Желаю Вам еще больших успехов
Здравствуйте, SiAVoL, Вы писали:
SAV>Все очень просто Просто никто не будет отказываться от WinAPI (кстати откуда дровишки?). WinAPI жил живет и будет жить. Вот то что в следующей ОС — Longhorn часть возможностей будет доступна только через управляемый код — это да, это есть. Но WinAPI никуда не денется
Не могли бы вы указать первоисточник? Неужели нельзя будет полноценно программировать под Longhorn без управляемого кода? Что-то не верится...
Здравствуйте, Edvard Grieg, Вы писали:
EG>Это я и так буду делать. В мелочах роюсь. Всегда. Привычка такая. Просто думаю что в мелочах всегда скрывается чтото важное. Есть ла в нете какиенибудь описания .NET на русском языке? Описания clr pe exe на русском, EG>самой архитектуры? Есть ли disassembler-ы? Отладчики?
Все есть в Джери Рихтер "Программирование на платформе Microsoft .NET Framework" у меня книжка печатная. А вот электронный вариант видел кажется видел на ftp://ftp.runnet.ru/BOOKS/ но не факт, что русский.
Здравствуйте, Gust, Вы писали:
G>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Это я и так буду делать. В мелочах роюсь. Всегда. Привычка такая. Просто думаю что в мелочах всегда скрывается чтото важное. Есть ла в нете какиенибудь описания .NET на русском языке? Описания clr pe exe на русском, EG>>самой архитектуры? Есть ли disassembler-ы? Отладчики?
G>Все есть в Джери Рихтер "Программирование на платформе Microsoft .NET Framework" у меня книжка печатная. А вот электронный вариант видел кажется видел на ftp://ftp.runnet.ru/BOOKS/ но не факт, что русский.
Здравствуйте, Nuald, Вы писали:
N>Не могли бы вы указать первоисточник? Неужели нельзя будет полноценно программировать под Longhorn без управляемого кода? Что-то не верится...
Здравствуйте, AndrewVK, Вы писали:
N>>Не могли бы вы указать первоисточник? Неужели нельзя будет полноценно программировать под Longhorn без управляемого кода? Что-то не верится...
AVK>longhorn.msdn.microsoft.com
Я там ничего такого не нашел. Я конечно понимаю, что WinFX написан как .NET сборки, и на неуправляемом коде будет тяжелее писать, но все-таки где написано, что некоторая функциональность доступна только из управляемого кода??
Здравствуйте, OldDino, Вы писали:
OD>Здравствуйте, Edvard Grieg, Вы писали:
OD>>>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
EG>>А вчем проблема их отдельно прилинковать? EG>>Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
OD>Н-да... Значит, по-Вашему, метаданные — это XML? Тяжело... А чем они линкуются, не подскажете?
EG>>Кстати скринсейвер longhorn-a если кто посмотрит самый обычный PEEXE файл обычнее некуда работает под W2K без всякого NET, но тем неменее meta-данные содержит
OD>Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
Ты знаешь, а это действительно можно, во всяком случае консольное приложение точно. Есть такая ось как RTOS, но осью ее назвать не совсем корректно, т.к. она грузится из обычного доса и запускает на сиполнение один виндовый процесс. Так что в принципе это и есть запуск виндового приложения из доса.
Это я видел несколько лет назад, как сейчас обстоят дела ХЗ, постоянно их реклама в журнале есть, который прософт выпускает. Фирма Он-Тайм ее изготовляет.
Здравствуйте, Denwer, Вы писали:
OD>>Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
D>Ты знаешь, а это действительно можно, во всяком случае консольное приложение точно. Есть такая ось как RTOS, но осью ее назвать не совсем корректно, т.к. она грузится из обычного доса и запускает на сиполнение один виндовый процесс. Так что в принципе это и есть запуск виндового приложения из доса. D>Это я видел несколько лет назад, как сейчас обстоят дела ХЗ, постоянно их реклама в журнале есть, который прософт выпускает. Фирма Он-Тайм ее изготовляет.
Ну, что можно сказать... Наверняка, есть где-то какие-нибудь эмуляторы, которые позволяют windows-программу запускать из-под DOS'а. Но, думаю, понятно, что это ТАКАЯ экзотика...
Тем не менее, благодарю за информацию. Принял к сведению.
OD>Ну, что можно сказать... Наверняка, есть где-то какие-нибудь эмуляторы, которые позволяют windows-программу запускать из-под DOS'а. Но, думаю, понятно, что это ТАКАЯ экзотика... :-)
OD>Тем не менее, благодарю за информацию. Принял к сведению.
OD>С уважением,
OD>OldDino
Есть к тому же WinEmu ,DosEmu под линью ребята абсолютно прекрасно реализовали интерфейс ntdll.dll и почти все Native API.
А откомпилировать win32 приложение под досом можно. Есть ребята которые умудрялись это делатьА есть такой товарищ gl00my -Peter Kosyh я его линкером досих пор пользуюсь когда ntokrnl ковыряю и ничего
Извините я конечно понимаю что все что я говорю смешно
P.S. наконецто до меня начинает доходить что такое meta-данные.
EG>А чтоже станет с дровами??? Будут ли дрова от WinXP,W2k переносимы на Longhorn или какбы точнее выразиться на платформу где уже будет легален только .NET.
Будут. Только не перенесены, а останутся. Что-то конечно изменится но совместимость останется. В общем, как и во всех ОС линейки NT.
EG>Что станет с Native API?
Будте жить дальше. Новое АПИ будет в основном менеджед. Но это не заставляет удалять старое.
EG>я просто помню заявление мелкомягких, что правильно написанный драйвер использующий EG>_только_ ресурсы hal для обращению к аппаратным ресурсам(без ассемблерных вставок), EG>будет переносим на различные другие платформы.
Будет.
EG>С учетом существования только managed code,
Не читайте перед едой Советских газет (с) Булгаков. Да и вообще не читайте (с) я. Если серьезно, то этот бредовый слух был распущен то ли Терой, то ли Компресом. Их авторы обычно ни ухом ни рылом не понимают в описываемой проблеме. Так что не стоит доверять информации из околокомпьютерных изданий.
EG> у меня создается впечатление что мелкомягкие стремятся к unix модели , когда есть микроядро оно в кольце 0,
Ну, в NT так оно и есть.
EG>а все остальное в том числе и дрова, в кольце 3.
А вот это вряд ли. Наоборот они вынесли все что смогли в нулевое кольцо. В четверке вынесли видиодрайверы, в 2003-ей вынесли хттп.
EG>Неужели они стремятся к этому?
Вряд ли. Они просто стремятся сделать хотя бы высокоуровневое АПИ более простым (т.е. дотнетным ).
EG>Опятьже все больше и больше Native API документируется мелкомягкими, а сколько я их(мелкомягких) помню они начинают документировать особенно выжные возможности EG>операционки перед ее моральной смертью.
Тогда какой-нить супер важный SendMessage должен был давно вымереть. А он живет с первых версий и будет жить в ЛХ.
EG>Вспомним даже не Native API и не Win32 а интерфейс Protected Storage базирующийся на EG>IUncknown , они опубликовали его где-то в феврале в msdn.
В СДК-шной документации он вроде был давно. Да и не в этом дело. Сидит отдел клепает доку. Поставили ему приоритеты — он сделал работу. Что там попадет, а что нет дело случая. Важные вещи конечно идут раньше, менее важные откладываются.
ЗЫ
В общем, не бери в голову. Все идет по спирали. Считай, что дотнет — это COM 2. Удобный такой, без кучи низкоуровневой лабуды, кучи проблем, оверхэда и т.п. В общем, новое поколение компонентного подхода. Тогда на все станет намного понятнее. Поймешь, что нет нужды уничтожать (по крайней мере сразу) все старые АПИ. Они прекрасно живут с новыми. Вот когда 90% программ будет жить исключительно на менеджед-АПИ, то можно будет начать задумываться об постепенном отказе от ВыньАПИ. Но будет это очень не скоро. Я оцениваю этот срок лет в 10.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuald, Вы писали:
N>Не могли бы вы указать первоисточник?
Он тут уже 100 раз приводился. Сделай поиск по форумам.
N>Неужели нельзя будет полноценно программировать под Longhorn без управляемого кода? Что-то не верится...
Это что считать полноценным. Программы создавать можно будет. И даже получить доступ ко многим новым фичам можно будет. Но вот будет это все через зад автогеном. Так что проще не выпендирваться и писать менеджед-код.
А ВыньАПИ-программы нужны будут если захочется делать ПО совместимое со всеми версиями.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И не тоелько. O/R мапинг не будет доступен в полном объеме и удобстве. Индиго тоже будет только интеропом. Так что все новые АПИ будут жить в режиме совместимости.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, rus blood, Вы писали:
RB>Это почему? WinAPI — не есть "винда" (а gnu — это не "юникс" ). RB>Win32 — это всего лишь платформа, построенная поверх Native API (реализованный в ntdll.dll, который работает поверх ntoskrnl.exe). RB>Так что выкинуть Win32 — не проблема, по крайней мере, не принципиальная проблема.
И чего этим можно добиться? Интероп все равно останется. Старые приложения все как один перестанут работать. Прийдется переписать море кода так как лов-велвел очень скуден. В итоге море геморроя и никаких бенефитов.
RB>Скорее наоборот, в след. системах Win32 будет эмулироваться поверх чего-то другого (для совместимости), а потом отомрет, когда-нить...
Зачем?
ЗЫ
Слава богу, в МС маньяки в основном в пиаре работают.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Edvard Grieg, Вы писали:
EG>И еще самое главное: EG>А кто собственно мешает воспользоваться mscoree.dll из обычного самого что нинаесть стандартного PEEXE WIN32?????
PEEXE никогда не относился к WIN32. Он и на Юниксах неплохо работает. Скчай Ротор, убедись.
EG>Hinst = Loadlibrary("mscoree32.dll"); EG>GetXMLElement = GetProcAddress(Hinst,"GetXMLElement"); EG>GetXMLElement(); EG>и т.д. EG>????
Ну, например то что mscoree32.dll не экспортирует таких фонкций. Загрузка дотнета в процес идет через COM. И менеджед АПИ может быть доступно анменеджед-миту толко чрез COM или через обертки на менеджед С++.
EG>я конечно понимаю что я наверное непонимаю о чем говорю,MSVC.NET не установлен EG>но я подозреваю что можно писать .NET приложения даже на BorlandDelphi 3.0 EG>
А ты попробуй. Зачем годать то? Облом я тебе конечно гарантирую. Но процесс увлекательный. За одно домыслы превратятся в понимание.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Это я и так буду делать. В мелочах роюсь. Всегда. Привычка такая. Просто думаю что в мелочах всегда скрывается чтото важное. Есть ла в нете какиенибудь описания .NET на русском языке? Описания clr pe exe на русском, EG>самой архитектуры? Есть ли disassembler-ы? Отладчики?
Купи Рихтера (только не того, что о Вынь32), а того что о дотнете. Там как раз с докапыванием до относительно низкого уровня (но в рзумных пределах).
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gust, Вы писали:
G>Все есть в Джери Рихтер "Программирование на платформе Microsoft .NET Framework" у меня книжка печатная. А вот электронный вариант видел кажется видел на ftp://ftp.runnet.ru/BOOKS/ но не факт, что русский.
Не на русском даже полезнее (если конечно язык знаешь). А то в нашем переводе ошибок многовато.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Большое спасибо EG>Попробую у когонибудь с хорошим каналом это вытянуть
Очень советую тянуть не это, а бэту второго дотнета. Тут где-то рядом ссылка есть. Там дают студию (C# Express) и урезанный МСДН. Их как раз достаточно чтобы комфортно "начать". Ну, и там куча разных вкусностей.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Очень советую тянуть не это, а бэту второго дотнета. Тут где-то рядом ссылка есть. Там дают студию (C# Express) и урезанный МСДН. Их как раз достаточно чтобы комфортно "начать". Ну, и там куча разных вкусностей.
А вы не подскажете в интернет магазинах он где-нибудь продается за символическую цену?
... << RSDN@Home 1.1.4 beta 1 >>
Re[8]: Чтоже такое dot.net??
От:
Аноним
Дата:
10.07.04 05:48
Оценка:
VD>PEEXE никогда не относился к WIN32. Он и на Юниксах неплохо работает. Скчай VD>Ротор, убедись.
На юниксах я уже 15 лет сижу. Там elf формат выполнен по стандарту coff.
С него был слизан мелкомягкими PEEXE. но одна беда заголовки разные.
Таблицы импорта разные и многие детали разные
dll -к примеру в *nix не существует
Другое дело что в WinNT реализована подсистема POSIX
Re[4]: Чтоже такое dot.net??
От:
Аноним
Дата:
10.07.04 06:20
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Edvard Grieg, Вы писали:
VD>В общем, не бери в голову. Все идет по спирали. Считай, что дотнет — это COM 2. Удобный такой, без VD>кучи ,низкоуровневой лабуды, кучи проблем, оверхэда и т.п. В общем, новое поколение компонентного подхода. Тогда VD>на все станет намного понятнее. Поймешь, что нет нужды уничтожать (по крайней мере сразу) все старые АПИ. Они VD>прекрасно живут с новыми. Вот когда 90% программ будет жить исключительно на менеджед-АПИ, то можно будет начать VD>задумываться об постепенном отказе от ВыньАПИ. Но будет это очень не скоро. Я оцениваю этот срок лет в 10.
Спасибо за нормальные безпаниковые ответы
Вчера уже влепил себе Visual Studio Net. Architect какуюто (какую нашел)
уже потихоньку начинаю осваиваться. Незнаю есть ли смысл изучать C#?
В целом понравилось. Действительно удобно.
Осталось MSDN утянуть и SDK-шки .
Мечтаю утянуть DDK под LongHorn.
Вчера связался еще с некоторыми ребятами из китая , они сообщили что в LongHorn
DDK вовсю уже поддерживается PCI Express, что удобно. Говорят еще целая куча фич появилась.
Кстати о поддержке HttpServer -a 2003 , где этот spud.sys взять? Или IIS который бы в комплекте его содержал?
Re[7]: Чтоже такое dot.net??
От:
Аноним
Дата:
10.07.04 06:24
Оценка:
VD>Я плякаль. Давай я тебе еще экзешник от Ворда вышлю, а ты нам напишешь о том, что это за продукт...
VD>Слабо скачать дотнет и попробовать написать программу?
Скачать очень слабо Почти не вероятно
4800 kbps — скорость королей
На рынке уже купил , на вещевом у знакомого заказал он в Москву за шмоткой ездил и наконец-то привез,
а пока я его ждал я задавал тут глупые вопросы чтобы покрайней мере на обсасывание таких мелочей,
время не тратить когда компилятор будет.
И вот он уже есть
Re[8]: Чтоже такое dot.net??
От:
Аноним
Дата:
10.07.04 06:28
Оценка:
имелось в виду 4800 bps я часто так ошибаюсь потому что параллельно занят кучей других вещей Вопрос а можно ли редактировать сообщение уже после того как запостил его?
Здравствуйте, <Аноним>, Вы писали:
А>Вчера уже влепил себе Visual Studio Net. Architect какуюто (какую нашел)
Если она 1.0, то советую найти 1.1, а лучше 2.0 бету.
А>уже потихоньку начинаю осваиваться. Незнаю есть ли смысл изучать C#?
Дык без него дотнет не понять.
А>Осталось MSDN утянуть и SDK-шки .
SDK не нужен если студия стоит. Минимум SDK и примеры в ней есть.
А>Мечтаю утянуть DDK под LongHorn.
Для этого нужно еще и сам ЛХ установить.
А>Вчера связался еще с некоторыми ребятами из китая, они сообщили что в LongHorn А>DDK вовсю уже поддерживается PCI Express, что удобно. Говорят еще целая куча фич появилась.
Естествнно. Новая версия винды как не как.
А>Кстати о поддержке HttpServer -a 2003 , где этот spud.sys взять? Или IIS который бы в комплекте его содержал?
Поставить тот самый Вынь2003, ХРюшу СП2 или ЛХ. Без этого смысла нет. И вообще, мне кажется ты слишком помернут на низком уровне. Я тоже не прочь залезть в "кишики", но начинать с этого, по-моему, не стоит.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>PEEXE никогда не относился к WIN32. Он и на Юниксах неплохо работает. Скчай VD>Ротор, убедись. А>На юниксах я уже 15 лет сижу. Там elf формат выполнен по стандарту coff. А>С него был слизан мелкомягкими PEEXE. но одна беда заголовки разные. А>Таблицы импорта разные и многие детали разные А>dll -к примеру в *nix не существует А>Другое дело что в WinNT реализована подсистема POSIX
Причем тут все это? я тебе сказал, что тот самый NT-евый PE (а точнее уже дотнетный) без изменений запускается на всех версиях виндовс и уних где есть клоны дотнет (моно или ротор). Как и Ява-вные, дотнетные модули не требуют пересборки для других платформ.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, woto, Вы писали:
W>Здравствуйте, VladD2, Вы писали:
VD>>Очень советую тянуть не это, а бэту второго дотнета. Тут где-то рядом ссылка есть. Там дают студию (C# Express) и урезанный МСДН. Их как раз достаточно чтобы комфортно "начать". Ну, и там куча разных вкусностей.
W>А вы не подскажете в интернет магазинах он где-нибудь продается за символическую цену?
Он доступен бесплатно на сайте МС. Еще раз повторюя, сделай поиск по нашим форумам и найдешь ссылку на место где можно скачать все это дело.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
W>>Здравствуйте, VladD2, Вы писали:
VD>Он доступен бесплатно на сайте МС. Еще раз повторюя, сделай поиск по нашим форумам и найдешь ссылку на место где можно скачать все это дело.
Так в смысле как раз и нету возможности его скачать .
Он бесплатный же? Я точно не уверен состоите ли вы в команде RSDN Team, и не нарушает ли это какие-то правила microsoft'a, но все таки спрошу. Можно ли надеяться что он будет идти в комлпекте с журналом RSDN, а то ролики эти уже запарили .
Здравствуйте, Silver_s, Вы писали:
S_> Раз уж заговорили о низком уровне.... S_>Ну пытаются .NET поближе к ядру подтянуть, WinAPI заменить итд. Но насколько близко в Longhorn он к ядру будет интересно. S_> Сейчас у .NET не то чтобы статус, скажем, скрипта в веб браузере. Но все же где то на этом уровне — просто поверхностная оболочка какая то. S_>А разница большая насколько он близок к ядру.
S_> Будет ли когда нибудь централизованое управление памятью. Что имеем сейчас — один .NET процесс может с легкой руки сотню другую мегабайт ОЗУ мусора держать. Система может попасть в глубокий своп из-за нехватки памяти. А мусорщиков в .NET процессе никто пинать сейчас не собирается, они по своему усмотрению действуют. S_> Другими словами мусор в .NET процессе не является мусором для всей системы.
не, ты не прав. Оттяпывает он столько потому что не убирает мусор. Потому что возможно его и не надо будет убирать, а надо будет грохнуть целиком. Либо вообще не потребуется свободная память. А как только ее становится не хватать — быстренько все убирается и никакого свопа
Здравствуйте, VladD2, Вы писали:
VD>Это что считать полноценным. Программы создавать можно будет. И даже получить доступ ко многим новым фичам можно будет. Но вот будет это все через зад автогеном. Так что проще не выпендирваться и писать менеджед-код.
Автоген тут не причем. Мне приходится часто писать кросс-платформенные приложения, и если на данный момент слой чистого win-кода не особо большой, то после перехода на управляемый код все кардинально изменится — даже не уверен, удастся ли писать такие приложения...
И еще — что же получается — сам длинный рог дофига будет жрать ресурсов, но если под ним будут крутится только приложения под .NET, то это вообще будет полный абзац — это же какие ресурсы нужны будут тачке... Что-то у меня сомнения приживется ли он в России, если конечно, к выпуску рога все регионы не станут такими же богатыми как москва, чтобы можно было во всех офисах ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители...
Здравствуйте, oRover, Вы писали: R>не, ты не прав. Оттяпывает он столько потому что не убирает мусор. Потому что возможно его и не надо будет убирать, а надо будет грохнуть целиком. Либо вообще не потребуется свободная память. А как только ее становится не хватать — быстренько все убирается и никакого свопа
Интересно как можно "грохнуть целиком"
Системный пэйджер каждому процессу (а после некого копяния я пришел к выводу что .NET процесс -обычный процесс для ядра (объект процесса со всеми причиндалами и плюшками остался тем-же)) выделяет энное кол-во памяти для загрузки процесса, а потом по его требованию malloc()-ки какие нибудь (new) [heap]и т.д. (в конечном итоге ExAllocatePool и т.д.)
я конечно понимаю что есть auto_ptr -ы всякие но даже этого хватит чтобы эффективная сборка мусора стала похожа на идиотизм:
int &TrashGenerator()
{
int i = 2;
return i;
}
main(*argv[] , int argc)
{
int &NextTrash = TrashGenerator()
RecieverTemporallyObject()
return 0;
}
Вы полагаете такой мусор можно будет убирать?
Хотя по теории если код управляем то наверняка возможно как-то.
Или есть надежды цто все будут писать стройно и поправилам?
Если этот код посмотреть после компиляции в Win32 будет что-то похожее:
;чтото там
call TrashGenerator
pop eax
push eax
call RecieverTemporallyObject() // так или иначе ресивер получит временный объект
//который проинициализирует какиелибо данные внутри:RecieverTemporallyObject()
// и приводит к ошибке, если ктото непонял о чем речь кину работоспособный исходник.
И такие ошибки копятся в выделенной страничной памяти как снежный ком.
Лишь изредка диспетчер когда все в PASSIVE_LEVEL и работает лишь idle,
очищает и обнуляет "запачканные" страницы.
Как будет происходить очистка именно от такого мусора я непредставляю себе
Но книгу Рихтера уже всетаки заказываю на днях
Здравствуйте, Nuald, Вы писали:
N>Что-то у меня сомнения приживется ли он в России, если конечно, к выпуску рога все регионы не станут такими же богатыми как москва, чтобы можно было во всех офисах ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители...
два года ( + год-два на распространение ОС) у регионов есть что бы приобрести что-то вроде P-IV. Так что все нормально
Здравствуйте, oRover, Вы писали:
R>не, ты не прав. Оттяпывает он столько потому что не убирает мусор. Потому что возможно его и не надо будет убирать, а надо будет грохнуть целиком. Либо вообще не потребуется свободная память. А как только ее становится не хватать — быстренько все убирается и никакого свопа
Я не заметил чтобы мусорщик включался когда системе не хватает памяти. Он может включиться когда самому .NET процессу не хватает памяти. Если оттяпать большой кусок памяти, и обнулить ссылку и сразу оставить .NET процесс на холостом ходу, и переключиться из него на другой процесс. То не известно соберет ли мусорщик когда нибудь этот мусор.
Еще память расходуется из-за того что процессы держат многие десятки мегабайт одинаковых стандартных библиотек в памяти.
S_> Я не заметил чтобы мусорщик включался когда системе не хватает памяти. Он может включиться когда самому .NET процессу не хватает памяти. Если оттяпать большой кусок памяти, и обнулить ссылку и сразу оставить .NET процесс на холостом ходу, и переключиться из него на другой процесс. То не известно соберет ли мусорщик когда нибудь этот мусор.
А разве у .NET процессов IRQL выше PASSIVE_LEVEL ?
Многозадачность вроде никто не отменял мне кажется в таком случае как раз Runtime
и должен проявить свою мощь Объект без указателя (хендла какойлибо ссылки как хотите вобщем) должен быть уничтожен если счетчик ссылок на объект достигнет 0
Это помоему былобы разумно.
S_> Еще память расходуется из-за того что процессы держат многие десятки мегабайт одинаковых стандартных библиотек в памяти.
Это да однозначно mscoree не грузится статически
И поэтому кажный процесс получает по екземпляру mscoree и нетолько
Что вобщемто как бы меня не убеждали ресурсо-неэффективно
Здравствуйте, Edvard Grieg, Вы писали:
EG>Это да однозначно mscoree не грузится статически EG>И поэтому кажный процесс получает по екземпляру mscoree и нетолько EG>Что вобщемто как бы меня не убеждали ресурсо-неэффективно
Здравствуйте, Silver_s, Вы писали:
S_> Еще память расходуется из-за того что процессы держат многие десятки мегабайт одинаковых стандартных библиотек в памяти.
в случае с DLL это не так,
сегменты кода DLL могут шариться м/у процессами.
EG>А разве у .NET процессов IRQL выше PASSIVE_LEVEL ? EG>Многозадачность вроде никто не отменял мне кажется в таком случае как раз Runtime
Просто у сборщика мусора довольно хитрый и сложный алгоритм определения момента когда нужно включаться.
EG>и должен проявить свою мощь Объект без указателя (хендла какойлибо ссылки как хотите вобщем) должен быть уничтожен если счетчик ссылок на объект достигнет 0 EG>Это помоему былобы разумно.
Вобщето в .NET нет никаких счетчиков ссылок. Там мусор по другому собирают. Есть объекты которые крепятся, скажем, к аппаратным ресурсам-их удалять нельзя, они ссылаются на другие объекты. Таким образом обходится все дерево из них растущее . Все что в дерево не вошло — все это мусор подлежащий удалению — но неизвестно когда, когда жареный петух клюнет.
Внутри одного .NET процесса управление памятью довольно эффективное, но каждый такой процесс думает только о себе.
А несколько десятков таких процессов, если не будут как то согласовывать распределение памяти, будут использовать память очень не эффективно. Нужен какой то профсоюз мусоршиков из всех процессов.
S_>> Еще память расходуется из-за того что процессы держат многие десятки мегабайт одинаковых стандартных библиотек в памяти.
EG>Это да однозначно mscoree не грузится статически EG>И поэтому кажный процесс получает по екземпляру mscoree и нетолько EG>Что вобщемто как бы меня не убеждали ресурсо-неэффективно
mscoree.dll это еще цветочки — 150 килобайт всего,а там еще мегабайтов 40, стандартных библиотек. Большая часть которых запросто может быть использована мелкой утилиткой.
Может это технически и нереально разделять общую память для кода стандартных библиотек на все процессы. Но тогда проблемы будут серьезные. Раньше то таких проблем не было до .NET — так как такого количества стандартных библиотек просто не было. И с каждой новой версией их количество быстро увеличивается.
Если запускать только 1-3 .NET процесса то никаких проблем. А если больше то кривовато пока.
ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители... SAV>два года ( + год-два на распространение ОС) у регионов есть что бы SAV>приобрести /что-то вроде P-IV. Так что все нормально
У регионов еще 80286 несписанные стоят и пашут
Срок списания и амортизации техники у регионов несколько иной.
Регионы потому и стремяться перейти на OpenSource(Linux,FreeBSD и т.д.)
я в частности был вынужден все коммуникационные серваки на работе,
как впрочем и почтовые перенести на FreeBSD, в связи с тем что
мелкомягкие всечаще интересуются лицензионностью софта.
А техническая поддержка мелкомягких как и всех остальных в регионах не более чем красивая сказка.
Потому и стремяться все купить если приложение бизнес-логики банковской то
RS-BANK, потому как rsl потому как все перекопать можно под себя
Потому и OpenSource что все проблемы и так на конечном пользователе висят,
дык проще с OpenSource разобраться чем с уже откомилированным кодом от Мелкомягких
Тут речь даже не о том как перейти на .NET а о том как нанего неперейти с наиболее
низкими затратами и прочими издержками.
Хороше что мне тут сообщили о том что есть mono. Теперь буду еще и его искать.
Незнаю есть ли версии под FreeBSD.
К примеру Celeron 800 -считается нормальной даже высокопроизводительной тачкой для регионов сейчас
И списаны Celeron 800 будут лет эдак через 10-15
Просто я понимаю что .NET это неотвратимое будующейй для России,а для Москвы уже настоящее
Поэтому изза этой неотвратимости я должен все взвесить и принять решение, не стоит ли пользоваться Linux + mono. Так как линь всетаки является более экономным и расчетливым нежели Winь .
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Edvard Grieg, Вы писали:
EG>>А разве у .NET процессов IRQL выше PASSIVE_LEVEL ? EG>>Многозадачность вроде никто не отменял мне кажется в таком случае как раз Runtime
S_>Просто у сборщика мусора довольно хитрый и сложный алгоритм определения момента когда нужно включаться.
EG>>и должен проявить свою мощь Объект без указателя (хендла какойлибо ссылки как хотите вобщем) должен быть уничтожен если счетчик ссылок на объект достигнет 0 EG>>Это помоему былобы разумно.
S_>Вобщето в .NET нет никаких счетчиков ссылок. Там мусор по другому собирают. Есть объекты которые крепятся, S_>скажем, к аппаратным ресурсам-их удалять нельзя, они ссылаются на другие объекты. Таким образом обходится все S_>дерево из них растущее . Все что в дерево не вошло — все это мусор подлежащий удалению — но неизвестно когда, S_>когда жареный петух клюнет.
Спасибо за информацию но мне кажется что какраз так и происходит в у диспетчера NT,
есть дерево Lookaside List и время от времени диспетчеры всякие пробегают по всему дереву.
Но мне всеже кажется что щетчики должны быть, иначе откуда известно сколько веток отходит от уза дерева???
Здравствуйте, Nuald, Вы писали:
N>Автоген тут не причем. Мне приходится часто писать кросс-платформенные приложения, и если на данный момент слой чистого win-кода не особо большой, то после перехода на управляемый код все кардинально изменится — даже не уверен, удастся ли писать такие приложения...
Все универсальное убого. Так что тут заморчиваться не нужно. Все равно ты не сможешь обеспечить подержки всех фич всех ОС. Так что или выбирай Яву (возможно дотнет с Моно) или С/С++ и забивай на фичи ОС. Опять таки сможешь привинчивать ОС-специфичные фичи вручную.
N>И еще — что же получается — сам длинный рог дофига будет жрать ресурсов, но если под ним будут крутится только приложения под .NET, то это вообще будет полный абзац — это же какие ресурсы нужны будут тачке...
Каждая новая ОС будет жрать все больше и бльше ресурсов. По крайней мере до глобального рефакторинга или до переписывания с нуля. Это закон. Тут ничего не поделаешь. Только дотнет тут совершенно не причем. В том же ЛХ основную память сжирает MSSQL.
N> Что-то у меня сомнения приживется ли он в России, если конечно, к выпуску рога все регионы не станут такими же богатыми как москва, чтобы можно было во всех офисах ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители...
Такие сомнения я слышал по поводу всех без исключения версий ОС. Никогда в жизни они еще не подтверждались на практике. Приживание новой ОС — это вопрос времени. Как минимум компьютеры стареют и выходят из строя. Так что рано или поздно все перейдут на новые версии.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Edvard Grieg, Вы писали:
EG>У регионов еще 80286 несписанные стоят и пашут
Вот эти сказки лучше петь где-то в другом месте.
Двушки вымерли как диназавры. Отдельные экспонаты конечно можно найти, но к мэйнстриму это отношение не имеет. По официальной статистике Интел Россия обгоняет еврому по продажам процессоров.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, woto, Вы писали:
W>Так в смысле как раз и нету возможности его скачать .
Физической что ли?
W>Он бесплатный же?
Да.
W> Я точно не уверен состоите ли вы в команде RSDN Team,
Если красный значе есть, значит состою пока.
W> и не нарушает ли это какие-то правила microsoft'a, но все таки спрошу. Можно ли надеяться что он будет идти в комлпекте с журналом RSDN, а то ролики эти уже запарили .
Вряд ли. У МС есть жесткая и дурацкая политика на этот счет.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
[QUOTE]
Думаю, исключение System.IO.IOException вам обеспечено по причине «The process cannot access the file "test.txt" because it is being used by another process.» (Процесс не может достучаться
[/QUOTE]
Оно будет обеспечено _НЕ_ПО_ПРИЧИНЕ_ неправильной сборки мусора.
Это принцип. Так устроено все!
Там где зеканчивается это:
void Test()
{
TextWriter tw = new StreamWriter("test.txt",true);
tw.Write("123");
}
Так или иначе начинается вот это:
CreateFile
NtCreateFile();
Потом вот это:
int 2E;
Потом вот это:
ZwCreateFile
и т.д.
А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д.
Ради интереса стоит узнать что -такое PEB.
ObjectManager в дальнейшем следит за объектом процесса и хэндлами.
Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Здравствуйте, Serginio1, Вы писали:
EG>[QUOTE] EG>Думаю, исключение System.IO.IOException вам обеспечено по причине «The process cannot access the file "test.txt" because it is being used by another process.» (Процесс не может достучаться EG>[/QUOTE]
EG>Оно будет обеспечено _НЕ_ПО_ПРИЧИНЕ_ неправильной сборки мусора. EG>Это принцип. Так устроено все! EG>Там где зеканчивается это: EG>[CODE] EG>void Test() EG>{ EG> TextWriter tw = new StreamWriter("test.txt",true); EG> tw.Write("123"); EG>}
Здесь говорится о том, что файл не закроется по выходе из видимости, т.к. GC не сработает.
Поэтому
Для пренудительного закрытия файла (но не уничтожения объекта) EG>А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д. EG>Ради интереса стоит узнать что -такое PEB. EG>ObjectManager в дальнейшем следит за объектом процесса и хэндлами. EG>Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
"Первое, что делает GC во время сборки мусора – это принимает решение о том, что все выделенные блоки памяти в вашей программе — это как раз и есть мусор, и они вам больше не нужны К счастью, на этом GC не прекращает свою работу. Далее начинается утомительный поиск «живых» указателей на объекты по всем закоулкам приложения. Microsoft называет эти указатели «roots». В процессе поиска GC сканирует глобальную память программы (на рисунках обозначено как Global), стек (Stack – локальные переменные) и даже регистры процессора (CPU). Как мы знаем, каждый поток в программе имеет свой собственный стек, и CLR приходится сканировать их все. Кроме того, интересен тот факт, что CLR умеет работать даже с потоками, которые создавались в неуправляемом коде с использованием функций WinAPI."
Но когда объектов много начинается write barier. По сути такое впечатление, что GC держит впостроенный граф достижимых объектов, и при изменении сылок на объект пересчитывает этот граф. При этом память не выделяется и нет никакого смысла в этом. Легче заного этот граф построить в при достижении порога памяти.
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, woto, Вы писали:
W>>Так в смысле как раз и нету возможности его скачать .
VD>Физической что ли?
В смысле, а какой еще не бывает?
В смысле нету канала.
... << RSDN@Home 1.1.4 beta 1 >>
Re[10]: И что дальше будет с .NET?
От:
Аноним
Дата:
12.07.04 17:13
Оценка:
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Здравствуйте, Serginio1, Вы писали:
EG>>[QUOTE] EG>>Думаю, исключение System.IO.IOException вам обеспечено по причине «The process cannot access the file "test.txt" because it is being used by another process.» (Процесс не может достучаться EG>>[/QUOTE]
EG>>Оно будет обеспечено _НЕ_ПО_ПРИЧИНЕ_ неправильной сборки мусора. EG>>Это принцип. Так устроено все! EG>>Там где зеканчивается это: EG>>[CODE] EG>>void Test() EG>>{ EG>> TextWriter tw = new StreamWriter("test.txt",true); EG>> tw.Write("123"); EG>>}
S> Здесь говорится о том, что файл не закроется по выходе из видимости, т.к. GC не сработает. S> Поэтому S>
S> Для пренудительного закрытия файла (но не уничтожения объекта)
В этом и ловушка, может для .NET файл и не объект вовсе, ноколь скоро файл существует он самый настоящий объект ядра управляемый ObjectManager -ом
и находящийся тут ://..//c:\*
И далее применяются все законы работы с объектами ОС. Вот вчем все дело
Мне кажется не стоит забывать о том что .NET всеголишь верхний слой пока,
а вот законы определяет то что ниже
Как только ты закрываешь файл ты уменьшаешь счетчик объекта файл на единицу,
если никто другой объек открытым а именно этот-же хендл файла не держит объект-файл будет уничтожнен.
Если ты файл не закрыл (явно) счетчик объектов не уменьшился , деструктор по умолчанию закрывать файл не станет, кто его знает где этот хендл еще использоваться будет?
EG>>А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д. EG>>Ради интереса стоит узнать что -такое PEB. EG>>ObjectManager в дальнейшем следит за объектом процесса и хэндлами. EG>>Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
S> "Первое, что делает GC во время сборки мусора – это принимает решение о том, что S>все выделенные блоки памяти в вашей программе — это как раз и есть мусор, и они S>вам больше не нужны
Угу одна проблема есть разница между объекто -"файл" и блоком памяти
объект файл это какбы выразиться некая ссылка на объект.
Хендл это чтото похожее на расшаренную секцию , которая шарится для пользовательского режима менеджером объектов.
Не все так просто
К счастью, на этом GC не прекращает свою работу. Далее начинается утомительный поиск «живых» указателей на объекты по всем закоулкам приложения. Microsoft называет эти указатели «roots». В процессе поиска GC сканирует глобальную память программы (на рисунках обозначено как Global), стек (Stack – локальные переменные) и даже регистры процессора (CPU). Как мы знаем, каждый поток в программе имеет свой собственный стек, и CLR приходится сканировать их все.
Неужели :ds,cs, и прочие селекторы тож сканирует??
Или он надеется что .NET приложение нулевое кольцо захватит?
Кроме того, интересен тот факт, что CLR умеет работать даже с потоками, которые создавались в неуправляемом коде с использованием функций WinAPI."
S> Но когда объектов много начинается write barier. По сути такое впечатление, что GC держит впостроенный граф достижимых объектов, и при изменении сылок на объект
Иными словами он действительно содержит индексы и счетчики объектов:
Чтото похожее на.
struct Uncknown_Struct
{
DWORD CounterConnections;
OBJECT_TYPE Type;
OBJECT Obj;
PNODE Node;
PNEXT_BLOCK NextBlocks[CounterConnections];
}
Любая база данных представляет собой граф, а любой графф должен быть проиндексирован.
Для возможности нахождения кратчайшего пути к примеру методом рельефов.
>пересчитывает этот граф. При этом память не выделяется и нет никакого смысла в >этом. Легче заного этот граф построить в при достижении порога памяти.
Ага ну конечно заново отстроить всю структуру памяти, а где в это время данные временно хранить?
S>> Для пренудительного закрытия файла (но не уничтожения объекта) А>В этом и ловушка, может для .NET файл и не объект вовсе, ноколь скоро файл существует он самый настоящий объект ядра управляемый ObjectManager -ом А>и находящийся тут ://..//c:\* А>И далее применяются все законы работы с объектами ОС. Вот вчем все дело А>Мне кажется не стоит забывать о том что .NET всеголишь верхний слой пока, А>а вот законы определяет то что ниже А>Как только ты закрываешь файл ты уменьшаешь счетчик объекта файл на единицу, А>если никто другой объек открытым а именно этот-же хендл файла не держит объект-файл будет уничтожнен. А>Если ты файл не закрыл (явно) счетчик объектов не уменьшился , деструктор по умолчанию закрывать файл не станет, кто его знает где этот хендл еще использоваться будет?
FileStream это объект, содержащий в себе унманагед дескриптор файла. Поэтому он реализует интерфейс IDisposable для закрытия файла при финализации. Почитай статью там это все указано. EG>>>А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д. EG>>>Ради интереса стоит узнать что -такое PEB. EG>>>ObjectManager в дальнейшем следит за объектом процесса и хэндлами. EG>>>Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
S>> "Первое, что делает GC во время сборки мусора – это принимает решение о том, что S>все выделенные блоки памяти в вашей программе — это как раз и есть мусор, и они S>вам больше не нужны А>Угу одна проблема есть разница между объекто -"файл" и блоком памяти А>объект файл это какбы выразиться некая ссылка на объект. А>Хендл это чтото похожее на расшаренную секцию , которая шарится для пользовательского режима менеджером объектов. А>Не все так просто
Все достаточно просто. Достаточно взглянуть на коеструктор и финализатор
Нативный хэндл содержиться в поле объекта. А>К счастью, на этом GC не прекращает свою работу. Далее начинается утомительный поиск «живых» указателей на объекты по всем закоулкам приложения. Microsoft называет эти указатели «roots». В процессе поиска GC сканирует глобальную память программы (на рисунках обозначено как Global), стек (Stack – локальные переменные) и даже регистры процессора (CPU). Как мы знаем, каждый поток в программе имеет свой собственный стек, и CLR приходится сканировать их все. А>Неужели :ds,cs, и прочие селекторы тож сканирует?? А>Или он надеется что .NET приложение нулевое кольцо захватит?
GC работает только с объектами. Работу с хэндлами ведут объекты реализующие IDisposable
А>Кроме того, интересен тот факт, что CLR умеет работать даже с потоками, которые создавались в неуправляемом коде с использованием функций WinAPI."
S>> Но когда объектов много начинается write barier. По сути такое впечатление, что GC держит впостроенный граф достижимых объектов, и при изменении сылок на объект А>Иными словами он действительно содержит индексы и счетчики объектов: А>Чтото похожее на. А>struct Uncknown_Struct А>{ А>DWORD CounterConnections; // не нужно т.к. смотрятся только он достижимые объекты. А>OBJECT_TYPE Type;// не нужен т.к. из объекта есть выход на Type А>OBJECT Obj; А>PNODE Node; А>PNEXT_BLOCK NextBlocks[CounterConnections]; А>} А>Любая база данных представляет собой граф, а любой графф должен быть проиндексирован. А>Для возможности нахождения кратчайшего пути к примеру методом рельефов.
>>пересчитывает этот граф. При этом память не выделяется и нет никакого смысла в >этом. Легче заного этот граф построить в при достижении порога памяти. А>Ага ну конечно заново отстроить всю структуру памяти, а где в это время данные временно хранить?
Дело в том, что сбор мусора нужен когда памяти не достаточно. Кроме того после выполнение каких либо действий живых объектов останется мало, и затраты по слежением за графом просто не нужны. При этом выполняется огромная ненужная работа.
Поэтому хранить ничего не нужно. А отстроить заного граф по доступным объектам.
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
А>>struct Uncknown_Struct А>>{ А>>DWORD CounterConnections; // не нужно т.к. смотрятся только он достижимые объекты. А>>OBJECT_TYPE Type;// не нужен т.к. из объекта есть выход на Type А>>OBJECT Obj; А>>PNODE Node; А>>PNEXT_BLOCK NextBlocks[CounterConnections]; А>>}
Вернее не совсем так. Сначала строится граф доступных переменных и ссылки в объектах на которые ссылаются эти переменные, которые могут находится в статических полях, стеке, и регистрах. При сборке мусора (дефрагментации памяти) все ссыли корректируются.
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
if (FileStream._canUseAsync && useAsync) //Проверка асинхронный ли вызов?
//Есть ли нужда в WaitForSingleObject в дальныйшем?
{
this._handle = Win32Native.SafeCreateFile(text2, num1, share, security_attributes1, mode, 1073741824, Win32Native.NULL);
this._isAsync = true; // да это асинхронный вызов
}
else
{ this._handle = Win32Native.SafeCreateFile(text2, num1, share, security_attributes1, mode, 128, Win32Native.NULL);
this._isAsync = false; //нет вызов не асинхронный.
}
protected virtual void Dispose(bool disposing)
{ if (this._handle != null) //Хендл не зомби?
{
try
{
if (!this._handle.IsClosed) //Если хендл не закрыт
{
base.Flush(); //Выбросить буфферы на диск.
}
}
finally
{
this._handle.Close(); // Нихрена выбросить не получилось. Поэтому закрываем.
}
}
his._canRead = false; // Так как хэндла больше не существует,this._canWrite = false; // запрещаем всяческие обращения к нему .this._canSeek = false; // эти аттрибуты поидее сигнализируют о том что хэндла больше нет,this._buffer = null; // и его нужно как минимум создать заново.
}
Честно говоря непонял в чем проблема. Все по идее должно коректно отрабатывать.
Ну получается что после диспозанья, хендла больше нет,
тогда невижу причины по которой файл должен быть залочен.
Re[13]: И что дальше будет с .NET?
От:
Аноним
Дата:
13.07.04 09:38
Оценка:
Здравствуйте, Edvard Grieg, Вы писали:
Меня здесь забанили. Так что под анонимом. Большой разницы нет.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Честно говоря непонял в чем проблема. Все по идее должно коректно отрабатывать. EG>Ну получается что после диспозанья, хендла больше нет, EG>тогда невижу причины по которой файл должен быть залочен.
Если ты внимательно прочитаешь ту статью то в коде
void Test()
{
TextWriter tw = new StreamWriter("test.txt",true);
tw.Write("123");
}
После выхода из процедуры не будет вызван финализатор. При такой схеме финализатор буде т вызван только при сборе мусора и то не сразу, т.к.
объекты с финализатором отслеживаютс дополнительно и финализация происходит после сборки мусора
поэтому обычно принудительно вызывают
GC.Collect();
void WaitForPendingFinalizers();
WaitForPendingFinalizers
Останавливает текущий поток до завершения выполнения методов Finalize для всех объектов из F-reachable Queue (рис. 9).
Для того, чтобы вызвать финализатор из кода нужно вызвать Dispose метода IDisposable
void Test()
{
using (TextWriter tw = new StreamWriter("test.txt",true))
{
tw.Write("123");
}
}
Это уже гораздо лучше. Конструкция using генерирует код, аналогичный нашему примеру с try/finally, за тем исключением, что вместо метода Close она вызывает Dispose. Вполне логично предположить, что объект должен иметь в своём составе такой метод. Так и есть, мы можем использовать с этой конструкцией только те объекты, которые реализуют интерфейс IDisposable, содержащий в своём составе один единственный метод:
void Dispose();
Интерфейс IDisposable призван формализовать освобождение ресурсов в CLR. Он реализуется многими классами .NET Framework, в том числе и для уведомления клиентов об уничтожении объекта (Component, Container, Control).
Соответственно, если вы создаёте класс, использующий какие-либо ресурсы, вы также должны реализовать этот интерфейс и метод Dispose в соответствии со следующими требованиями (эти правила никак не обозначены в MSDN и взяты мной из комментариев к исходным текстам CLI):
Метод Dispose должен иметь возможность быть безопасно вызванным несколько раз.
Освобождать любые ресурсы, ассоциированные с экземпляром объекта.
Вызывать метод Dispose базового класса при необходимости.
Подавлять вызов метода Finalize путём удаления ссылки на объект из Finalization Queue.
Не должен генерировать исключения, кроме очень серьёзных случаев наподобие OutOfMemoryException. В идеале с вашим объектом не должно происходить ничего особенного в процессе вызова Dispose.
Давайте напишем класс, который бы соответствовал данным требованиям, и который можно было бы использовать в дальнейшем как базовый.
Спасибо большое за объяснения
Мне кажется класс мог бы выглядеть похожим на это:
template <class InputClass> class FileWorker
{
typedef struct _ERROR_COMMENT
{
bool IC_NOT_CREATED;
bool IC_ERROR_WRITE;
bool IC_ERROR_READ;
bool IC_ERROR_FLUSH;
bool IC_ERROR_CLOSE;
}ERROR_COMMENT,*PERROR_COMMENT;
InputClass *IC;
PERROR_COMMENT EC;
FileWorker(char *FileName)
{
ZeroMemory(EC,sizeof(ERROR_COMMENT));
if (typeid(InputClass)==typeid(TextWriter))
{
try
{
IC = new StreamWriter(FileName,true);
}
finally
{
IC_NOT_CREATED = TRUE;
}
}
};
Write (char *InputBuffer)
{
if (typeid(InputClass)==typeid(TextWriter))
{
try
{
IC->Write(InputBuffer);
}
finally
{
IC_ERROR_WRITE = TRUE;
}
}
}
char *Read ()
{
char OutputBuffer[MAX_LENGTH];
if (typeid(InputClass)==typeid(TextWriter))
{
try
{
IC->Read(OutputBuffer);
}
finally
{
IC_ERROR_READ = TRUE;
}
}
}
и т.д. потом должен быть такойже член класса для seek, для close, и т.д.
и блок статистики ошибок.
Блок статистики ошибок нужен бля того чтобы время от времени в зависимости от количества ошибок мажоритарная система контроля моглабы удалять класс и создавать заново.Или есть более удобные способы?:-)
И вообще чтото такое возможно на шарпе ? Если да то как:-)
я был бы очень благодарен за какой-нибудь такой примерчик:-)
}
Re[15]: И что дальше будет с .NET?
От:
Аноним
Дата:
13.07.04 11:36
Оценка:
Здравствуйте, Edvard Grieg, Вы писали:
EG> и т.д. потом должен быть такойже член класса для seek, для close, и т.д. EG> и блок статистики ошибок. EG> Блок статистики ошибок нужен бля того чтобы время от времени в зависимости от количества ошибок мажоритарная система контроля моглабы удалять класс и создавать заново.Или есть более удобные способы? EG>И вообще чтото такое возможно на шарпе ? Если да то как EG>я был бы очень благодарен за какой-нибудь такой примерчик
Ты можешь создать класс оболочку над FileStream наследника от Stream и реализовать все его абстрактные методы через экземпляр класса FileStream который будет полем этого класса или свой класс.
И соответствнно в нем ты можешь реализовать все что писал. При этом с экземпляр класса FileStream ты можешь делать что угодно. Обычнвя практика.
А> Ты можешь создать класс оболочку над FileStream наследника от Stream и реализовать все его абстрактные методы через экземпляр класса FileStream который будет полем этого класса или свой класс. А> И соответствнно в нем ты можешь реализовать все что писал. При этом с экземпляр класса FileStream ты можешь делать что угодно. Обычнвя практика.
Сегодня после работы попробую
Кстати тут статья про дженерики какаянибудь русскоязычная не пробегала нигде?
Здравствуйте, <Аноним>, Вы писали:
А>Меня здесь забанили. Так что под анонимом. Большой разницы нет.
Разница есть. Если тебя забанили это не означает что ты все равно можешь писать. И что особенно приятно — один черт ты продолжаешь делать то за что тебя собственно забанили. Вобщем ты рискуешь попасть в бан надолго.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, <Аноним>, Вы писали:
А>>Меня здесь забанили. Так что под анонимом. Большой разницы нет. AVK> Разница есть. Если тебя забанили это не означает что ты все равно можешь писать. И что AVK> особенно приятно — один черт ты продолжаешь делать то за что тебя собственно забанили. AVK> Вобщем ты рискуешь попасть в бан надолго.
Здравствуйте, VladD2, Вы писали:
VD>Все универсальное убого. Так что тут заморчиваться не нужно. Все равно ты не сможешь обеспечить подержки всех фич всех ОС. Так что или выбирай Яву (возможно дотнет с Моно) или С/С++ и забивай на фичи ОС. Опять таки сможешь привинчивать ОС-специфичные фичи вручную.
На уровне исходников не убого — иначе не было бы игр, которые нормально работают на PC и PS2 (например, Silent Hill <версия>)... А фичи я и не собираюсь поддерживать — просто иногда есть такие подляческие фичи, что на них приходится ориентироваться... Сколько нам проблем составило все нормально заработать под Win98, когда на Win2k все крутилось идеально... После выхода длинного рога ИМХО ситуация будет еще хуже (лишь надеюсь, что мелкомягкие все-таки откажутся от официальной поддержки 98-ой)..
VD>Каждая новая ОС будет жрать все больше и бльше ресурсов. По крайней мере до глобального рефакторинга или до переписывания с нуля. Это закон. Тут ничего не поделаешь. Только дотнет тут совершенно не причем. В том же ЛХ основную память сжирает MSSQL.
Никогда такого не слышал... Помню еще OS/2 работала достаточно хорошо на слабой тачке, когда для винды нужно было для тех же задач куда больше ресурсов...
И причем MSSQL и рог?? Мелкомягкие их что-ли интегрируют друг в друга??? После этого точно лучше вообще отказаться от них — не надо нам таких фич, не хватало чтобы еще пользовательская машина стала источников неимоверных дыр (то, что код управляемый не означает что в нем не может быть переполнение буфера и т.п.)...
VD>Такие сомнения я слышал по поводу всех без исключения версий ОС. Никогда в жизни они еще не подтверждались на практике. Приживание новой ОС — это вопрос времени. Как минимум компьютеры стареют и выходят из строя. Так что рано или поздно все перейдут на новые версии.
ИМХО вы не работали в госструктурах, или в организациях, которые еще живут по совковскому принципу — "Работает, так и ладно, незачем тратить деньги на всякую лабуду"...
Здравствуйте, VladD2, Вы писали:
VD>N(например, Silent Hill <версия>)... VD>Потому эта игра и не является Far Cry-ем.
Никто и не спорит. Но с другой стороны, никто не будет писать и .NET такого рода игры (по-крайней мере, я надеюсь). Не надо тут про Ил-2, в котором AI были на яве — они потом сами признались, что это было глупо...
Хотя конечно, если в .NET сделают гибкое управление сборщиком мусора, поддержку SSE/2/3, нормальную предкомпиляцию и всякие другие фичи, то тогда все будет путем... Но это пока лишь мечты...
VD>Агащасблин. 95-ые была куда производительнее на том же железе чем полуось. Эти сказки рассказывай тем кто сам не выбросил полуось после выхода 95-ых и NT 3.5.
Привожу "цифры". Это была 4-ка (не пень 4, а 486 ), который держал на себе ftp, lotus domino 4, почту и при этом еще был шлюзом. Там вроде еще что-то было, не помню. 95-я там бы не продержалась и нескольких часов. Только это была не Warp, а еще до нее, не помню, как называлось..
VD>Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL.
Можно первоисточник?
N>>После этого точно лучше вообще отказаться от них — не надо нам таких фич, не хватало чтобы еще пользовательская машина стала источников неимоверных дыр (то, что код управляемый не означает что в нем не может быть переполнение буфера и т.п.)... VD>"Вам" то может и следует. Вот только эти вопросы стоит осбуждать в священных войнах. А для большей честности стоит еще и пересесть на какой-нить ликух.
А причем тут линукс? Я на нем иногда сижу, но он тоже достаточно дырявый... Как десктоп-система, конечно, Винда лучше, но стоит ли десктоп превращать в сервер, вот в чем вопрос...
N>>ИМХО вы не работали в госструктурах, VD>Я себе не враг.
А мне вот довелось
N>>или в организациях, которые еще живут по совковскому принципу — "Работает, так и ладно, незачем тратить деньги на всякую лабуду"... VD>Ну, и будт работаь пока техника не сдохнет. А сдохнет, купят новую с ЛХ или еще чем нибудь поновее.
А программы-то сейчас нужны — и под эти дохлые тачки тоже...
Здравствуйте, Nuald, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>N(например, Silent Hill <версия>)... VD>>Потому эта игра и не является Far Cry-ем.
N>Никто и не спорит. Но с другой стороны, никто не будет писать и .NET такого рода игры (по-крайней мере, я надеюсь). Не надо тут про Ил-2, в котором AI были на яве — они потом сами признались, что это было глупо... N>Хотя конечно, если в .NET сделают гибкое управление сборщиком мусора, поддержку SSE/2/3, нормальную предкомпиляцию и всякие другие фичи, то тогда все будет путем... Но это пока лишь мечты...
Насчет игр — можно посмотреть Quake2.NET А чем не нравиться теперешняя предкомпиляция и сборщик мусора ? И как представляется поддержка SSE... Это в плюсах реализованно...
VD>>Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL.
N>Можно первоисточник?
WinFS + Yukon
Здравствуйте, Nuald, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>N(например, Silent Hill <версия>)... VD>>Потому эта игра и не является Far Cry-ем.
N>Никто и не спорит. Но с другой стороны, никто не будет писать и .NET такого рода игры (по-крайней мере, я надеюсь).
Будут. Еща как будут. Вот преодалеют в себе догмы и будут. Да что уж там... Уже пишут потихоничку.
N> Не надо тут про Ил-2, в котором AI были на яве — они потом сами признались, что это было глупо...
Можно ссылку?
N>Хотя конечно, если в .NET сделают гибкое управление сборщиком мусора,
Ненадо гигкой. Она и так очень неплохая. 99% программистов лучше не напишут.
N> поддержку SSE/2/3,
Сделают обязательно. Кое что уже сделали.
N> нормальную предкомпиляцию и всякие другие фичи, то тогда все будет путем... Но это пока лишь мечты...
Скорость кода в дотнете уже лучше многих С++ компиляторов. ЖЦ тоже не является проблемой. Потери в следствии интероп тоже можно минимизировать. А вот выигрыш в скорости разработки, переносимости, и надежности есть очень немалый. Так что игры на дотнете — это вопрос времени.
VD>>Агащасблин. 95-ые была куда производительнее на том же железе чем полуось. Эти сказки рассказывай тем кто сам не выбросил полуось после выхода 95-ых и NT 3.5.
N>Привожу "цифры". Это была 4-ка (не пень 4, а 486 ), который держал на себе ftp, lotus domino 4, почту и при этом еще был шлюзом. Там вроде еще что-то было, не помню. 95-я там бы не продержалась и нескольких часов. Только это была не Warp, а еще до нее, не помню, как называлось..
Причем тут сервер? Мы кажется о клиентах говорим. Как сервер варп тоже был тоже не зашибись. Валился от превого зациклившегося приложения. Да и память для сервера желеть во времена варп-конекта было просто смешно.
VD>>Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL.
N>Можно первоисточник?
А чтобы плеваться по чаще.
N> Я на нем иногда сижу, но он тоже достаточно дырявый... Как десктоп-система, конечно, Винда лучше, но стоит ли десктоп превращать в сервер, вот в чем вопрос...
Стоит. Вот наш сайт живет себе на 2003-их виндах и в ус не дует. Администрировать легко, отлаживать удобно. Что еще нужно?
N>А мне вот довелось
Сочувствую.
N>А программы-то сейчас нужны — и под эти дохлые тачки тоже...
Госструктуры довольно хреновый ориентир. Все равно без волосатой лапы на них сделать деньги нельзя. А с ней особых умений в области программирования не нужно. Так что доростут — купят сами, а пока будем ориентироваться на коммерческий рынок.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Edvard Grieg, Вы писали:
EG>>У регионов еще 80286 несписанные стоят и пашут
VD>Вот эти сказки лучше петь где-то в другом месте.
VD>Двушки вымерли как диназавры. Отдельные экспонаты конечно можно найти, но к VD>мэйнстриму это отношение не имеет. По официальной статистике Интел Россия VD>обгоняет еврому по продажам процессоров.
Это далеко не сказки к сожалению, может ктото и обгоняет европпу но у нас однозначно
45% парка 80x286 80x386.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Это далеко не сказки к сожалению, может ктото и обгоняет европпу но у нас однозначно EG>45% парка 80x286 80x386.
Нормально работающие двушки в наше время — это антиквариат. Если ваша контора погрязла в нищите, то не надо проецировать это положение на всю страну. Я как бы не даром скзал, что для Интела наш рынок уже важнее чем европейский. В общем, если не веришь создай голосование какие компьютеры в соновном есть у вас на предприятии.
Равняться на нищенство просто глупо. Люди скупящиеся на современное железо за софт точно платить не будут. В конце коцов — это русский менталитет "Софт фуфло".
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gtima, Вы писали:
N>>Хотя конечно, если в .NET сделают гибкое управление сборщиком мусора, поддержку SSE/2/3, нормальную предкомпиляцию и всякие другие фичи, то тогда все будет путем... Но это пока лишь мечты... G>Насчет игр — можно посмотреть Quake2.NET А чем не нравиться теперешняя предкомпиляция и сборщик мусора ? И как представляется поддержка SSE... Это в плюсах реализованно...
А что там смотреть — основная работа выполняется графической картой. Да и вообще попробуйте запустить q2.net на той тачке на которой сам q2 старый выдавал 30 fps...
Предкомпиляция идет долго и не всегда устойчиво (возможно, что сейчас вопросы с устойчивостью решены). Я опять-таки говорю про компы с процом ниже цел 500. На новых компах тестировать бесполезно — на них и явовский AWT-то не тормозит...
Поддержка SSE в виде библиотек или встроенной в JIT-компилятор. Возможно, что текущий компилятор уже такую поддержку осуществляет. Конечно, я не говорю о поддержке HT и нескольких процов (опять-таки на уровне библиотек и компилятора — на уровне ОСи бесполезно — винда пока еще глупо распределяет сама по себе ресурсы).
VD>>>Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL. N>>Можно первоисточник? G>WinFS + Yukon
Здравствуйте, VladD2, Вы писали:
VD>Будут. Еща как будут. Вот преодалеют в себе догмы и будут. Да что уж там... Уже пишут потихоничку.
Представляю. Тормозит лонгхорн, тормозит его графическая подсистема, и тормозит игра. Вот халява продавцам железа... Надо наверное срочно переквалифицироваться на железо — скоро народ валом попрет...
N>> Не надо тут про Ил-2, в котором AI были на яве — они потом сами признались, что это было глупо... VD>Можно ссылку?
N>>Хотя конечно, если в .NET сделают гибкое управление сборщиком мусора, VD>Ненадо гигкой. Она и так очень неплохая. 99% программистов лучше не напишут.
Напишут, если не будут халявить. Сборка мусора бывает разной, и хотя в микрософтвском .NET она сделано неплохо, но недостаточно гибко. Простое разделение кода на управляемый и неуправляемый — это не то... Скажем, я бы хотел работать с указателями, т.к. много старого кода, а вот удаление пусть будет делать сборщик... Либо скажем ввести контуры сборки с разными приоритетами — скажем для графической части приоритет низкий, чтобы сборщик только в крайнем случае делал очистку, а для бизнес-логики — высокий, т.к. здесь особые тормоза не будут заметны все-равно...
VD>Скорость кода в дотнете уже лучше многих С++ компиляторов. ЖЦ тоже не является проблемой. Потери в следствии интероп тоже можно минимизировать. А вот выигрыш в скорости разработки, переносимости, и надежности есть очень немалый. Так что игры на дотнете — это вопрос времени.
Игры — не факт, а с остальным не спорю, кроме того, что вызывает личную неприязнь, но не является объективным фактором (как скажем полное игнорирование STL в managed С++)...
VD>>>Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL. N>>Можно первоисточник? VD>http://longhorn.msdn.microsoft.com
Ничего такого я там не обнаружил. Там наоборот сказано, если судить по схемам, что WinFS базируется на NTFS с поддержкой реляционных отношений.
N>> Я на нем иногда сижу, но он тоже достаточно дырявый... Как десктоп-система, конечно, Винда лучше, но стоит ли десктоп превращать в сервер, вот в чем вопрос... VD>Стоит. Вот наш сайт живет себе на 2003-их виндах и в ус не дует. Администрировать легко, отлаживать удобно. Что еще нужно?
А легко ли на винде проставить, что такому-то чуваку ограничить скорость скачивания до 10 кбайт в секунду, а себе любимому — 100 кбайт в секунду? Возможно, что в 2003-ем сервере это можно, но меня берут дикие сомнения...
VD>Госструктуры довольно хреновый ориентир. Все равно без волосатой лапы на них сделать деньги нельзя. А с ней особых умений в области программирования не нужно. Так что доростут — купят сами, а пока будем ориентироваться на коммерческий рынок.
У нас, на Дальнем Востоке как такого коммерческого рынка ПО нет, так что нам тяжелее... Поэтому и приходится работать на запад...
N>Игры — не факт, а с остальным не спорю, кроме того, что вызывает личную неприязнь, но не является объективным фактором (как скажем полное игнорирование STL в managed С++)...
Как это так ? STL on the CLI. Планируется в VS 2005 Beta 2...
stdcli::vector<String^> v;
Еще для особых извращенцев
Windows Forms support has been added to MFC.
И еще —
Visual C++ 2005 supports the use of ATL, MFC, SCL, and the CRT libraries as mixed assemblies compiled with /clr
Здравствуйте, Nuald, Вы писали:
N>Представляормозит лонгхорн, тормозит его графическая подсистема, и тормозит игра. Вот халява продавцам железа... Надо наверное срочно переквалифицироваться на железо — скоро народ валом попрет...
Там таких умных как ты уже море.
N>Напишут, если не будут халявить. Сборка мусора бывает разной, и хотя в микрософтвском .NET она сделано неплохо, но недостаточно гибко.
Для чего недостаточно? Есть какие-то разумные и точные сведения? Или все же как всегда доверяем БНС?
N> Простое разделение кода на управляемый и неуправляемый — это не то... Скажем, я бы хотел работать с указателями, т.к. много старого кода,
Работай. Кто же тебе мешает? Единственная проблема с указателями — это огромное количество багов.
N>а вот удаление пусть будет делать сборщик...
Раз код старый, то и удалять память прийдется вручную.
N> Либо скажем ввести контуры сборки с разными приоритетами — скажем для графической части приоритет низкий, чтобы сборщик только в крайнем случае делал очистку, а для бизнес-логики — высокий, т.к. здесь особые тормоза не будут заметны все-равно...
И так все есть. Есть поколения. Те самые графические примитивы всегда помирают в первом поколении. Так что все ОК. Ты можешь вообще не следить за шрифтами, кистями и т.п. и при этом никаких ликов ресурсов не будет. Да и скорость системы будет очено даже неплохая.
N>Игры — не факт, а с остальным не спорю, кроме того, что вызывает личную неприязнь, но не является объективным фактором (как скажем полное игнорирование STL в managed С++)...
Да не игнорирует его никто. В менеджед-типах STL раньше было использовать нельзя, но в менеджед-коде запросто. В VC 2005 обещают, что STL можно будет использовать и в менеджед-структурах. Правда особой надобности в это нет. Дотнетные коллекции ничем не хуже, и совместимы с другими языками дотнета.
VD>>>>Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL. N>>>Можно первоисточник? VD>>http://longhorn.msdn.microsoft.com
N>Ничего такого я там не обнаружил.
Значит плохо смотрел.
N> Там наоборот сказано, если судить по схемам, что WinFS базируется на NTFS с поддержкой реляционных отношений.
В общем, если влом самому искать, то поверь на слово, что WinFS — это специализированная версия SQL Server 2005 над которой сделана настройка в виде объектной модели созданной на дотнете. Естественно, что в конечном итоге все лежит на NTFS-ых дисках. В обещм, мо сути WinFS — это и есть MSSQL. Стартует как отедьный сервис. Можно сирвис остановить. При этом, естественно, NTFS продолжает дальше прекрасно работать.
В общем, если влом искать, сделай поиск по по гуглю словосочетания WinFS Yukon и почитай...
N>А легко ли на винде проставить, что такому-то чуваку ограничить скорость скачивания до 10 кбайт в секунду, а себе любимому — 100 кбайт в секунду? Возможно, что в 2003-ем сервере это можно, но меня берут дикие сомнения...
Мы сейчас начнем очередную ветку Линь вс. Вынь? Я даже не знаю легко или нет. Мне этого не нужно. У нас 100 мегабайтный канал, а самый большой файл не привышает 100 мег. Причем за скачку с нас денег не буерут. За то, то что нужно делается легко и не придужденно. И на юниксы или линуксы как то не тянет. Причем не тянет в основном потому что там нет того самого .Net и MSSQL.
N>У нас, на Дальнем Востоке как такого коммерческого рынка ПО нет, так что нам тяжелее... Поэтому и приходится работать на запад...
Вам скорее нужно на восток работать . Но тут разницы между заподом, востоком и коммерческим ПО нет. Главное, что не на госструктуры.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuald, Вы писали:
N>А что там смотреть — основная работа выполняется графической картой. Да и вообще попробуйте запустить q2.net на той тачке на которой сам q2 старый выдавал 30 fps...
Получиш где-то 29 фис. Ну и что?
N>Предкомпиляция идет долго и не всегда устойчиво (возможно, что сейчас вопросы с устойчивостью решены). Я опять-таки говорю про компы с процом ниже цел 500. На новых компах тестировать бесполезно — на них и явовский AWT-то не тормозит...
АВТ и раньше не тормозил он нэйтивный. А вот Свинг тормозит на любой тачке.
VD>>>>Притом, что новая виртуальная фаловая система в ЛХ сделана на базе новой версии MSSQL. N>>>Можно первоисточник? G>>WinFS + Yukon
N>URL или цитата от сотрудников MS.
Мне говорил лично Дон Бокс. А вообще достаточно сделать поиск по гуглю WinFS + Yukon.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. А ничего преступного вроде в этом нет чтобы исполнялось 20-30 процессов в многозадачной системе. 
