Здравствуйте, VladD2, Вы писали:

VD>Очень советую тянуть не это, а бэту второго дотнета. Тут где-то рядом ссылка есть. Там дают студию (C# Express) и урезанный МСДН. Их как раз достаточно чтобы комфортно "начать". Ну, и там куча разных вкусностей.

А вы не подскажете в интернет магазинах он где-нибудь продается за символическую цену?

VD>PEEXE никогда не относился к WIN32. Он и на Юниксах неплохо работает. Скчай VD>Ротор, убедись.
На юниксах я уже 15 лет сижу. Там elf формат выполнен по стандарту coff.
С него был слизан мелкомягкими PEEXE. но одна беда заголовки разные.
Таблицы импорта разные и многие детали разные
dll -к примеру в *nix не существует
Другое дело что в WinNT реализована подсистема POSIX

Здравствуйте, 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 который бы в комплекте его содержал?

VD>Я плякаль. Давай я тебе еще экзешник от Ворда вышлю, а ты нам напишешь о том, что это за продукт...

VD>Слабо скачать дотнет и попробовать написать программу?

Скачать очень слабо Почти не вероятно
4800 kbps — скорость королей

На рынке уже купил , на вещевом у знакомого заказал он в Москву за шмоткой ездил и наконец-то привез,
а пока я его ждал я задавал тут глупые вопросы чтобы покрайней мере на обсасывание таких мелочей,
время не тратить когда компилятор будет.
И вот он уже есть

имелось в виду 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 или ЛХ. Без этого смысла нет. И вообще, мне кажется ты слишком помернут на низком уровне. Я тоже не прочь залезть в "кишики", но начинать с этого, по-моему, не стоит.

Здравствуйте, <Аноним>, Вы писали:


VD>>PEEXE никогда не относился к WIN32. Он и на Юниксах неплохо работает. Скчай VD>Ротор, убедись.
А>На юниксах я уже 15 лет сижу. Там elf формат выполнен по стандарту coff.
А>С него был слизан мелкомягкими PEEXE. но одна беда заголовки разные.
А>Таблицы импорта разные и многие детали разные
А>dll -к примеру в *nix не существует
А>Другое дело что в WinNT реализована подсистема POSIX

Причем тут все это? я тебе сказал, что тот самый NT-евый PE (а точнее уже дотнетный) без изменений запускается на всех версиях виндовс и уних где есть клоны дотнет (моно или ротор). Как и Ява-вные, дотнетные модули не требуют пересборки для других платформ.

Здравствуйте, woto, Вы писали:

W>Здравствуйте, VladD2, Вы писали:

VD>>Очень советую тянуть не это, а бэту второго дотнета. Тут где-то рядом ссылка есть. Там дают студию (C# Express) и урезанный МСДН. Их как раз достаточно чтобы комфортно "начать". Ну, и там куча разных вкусностей.

W>А вы не подскажете в интернет магазинах он где-нибудь продается за символическую цену?

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

Здравствуйте, <Аноним>, Вы писали:

А>Вопрос а можно ли редактировать сообщение уже после того как запостил его?

Нет. Но если очнь хочется, можно попросить об этом модератора. Твой случай этого явно не требует. Все и так все поняли.

Раз уж заговорили о низком уровне....
Ну пытаются .NET поближе к ядру подтянуть, WinAPI заменить итд. Но насколько близко в Longhorn он к ядру будет интересно.
Сейчас у .NET не то чтобы статус, скажем, скрипта в веб браузере. Но все же где то на этом уровне — просто поверхностная оболочка какая то.
А разница большая насколько он близок к ядру.

Будет ли когда нибудь централизованое управление памятью. Что имеем сейчас — один .NET процесс может с легкой руки сотню другую мегабайт ОЗУ мусора держать. Система может попасть в глубокий своп из-за нехватки памяти. А мусорщиков в .NET процессе никто пинать сейчас не собирается, они по своему усмотрению действуют.
Другими словами мусор в .NET процессе не является мусором для всей системы.

Реально ли уменьшить занимаемую память под .NET процессы хотябы до 10 мег.
Что сейчас происходит в памяти если запустить 20-30 .NET процессов. Оттяпают они судя по всему 1 гиг памяти. И начнется брутальный свопинг. А если в эту память как-то заглянуть то судя по всему из этого 1 гига, штук 800-900 мег будет просто повторяющиеся копипи одних и тех же кусков продублированных. Вот хорошо ли это . А ничего преступного вроде в этом нет чтобы исполнялось 20-30 процессов в многозадачной системе.

Вот когда винда научится держать 30 .NET процессов, не зашкаливая в потреблении памяти за 500 мег. Тогда только можно будет говорить о замене WinAPI.
Имеется ведь ввиду пороцессы практически без своего функционала, только стандартные фичи из .NET использующие.

Здравствуйте, 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 процесс на холостом ходу, и переключиться из него на другой процесс. То не известно соберет ли мусорщик когда нибудь этот мусор.

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

VD>Попробую повторить... [b]Разбираясь с дотнетом на таком низком уровене не вникая

Спасибо но все это я уже понял

S_> Я не заметил чтобы мусорщик включался когда системе не хватает памяти. Он может включиться когда самому .NET процессу не хватает памяти. Если оттяпать большой кусок памяти, и обнулить ссылку и сразу оставить .NET процесс на холостом ходу, и переключиться из него на другой процесс. То не известно соберет ли мусорщик когда нибудь этот мусор.

А разве у .NET процессов IRQL выше PASSIVE_LEVEL ?
Многозадачность вроде никто не отменял мне кажется в таком случае как раз Runtime
и должен проявить свою мощь Объект без указателя (хендла какойлибо ссылки как хотите вобщем) должен быть уничтожен если счетчик ссылок на объект достигнет 0
Это помоему былобы разумно.


S_> Еще память расходуется из-за того что процессы держат многие десятки мегабайт одинаковых стандартных библиотек в памяти.

Это да однозначно mscoree не грузится статически
И поэтому кажный процесс получает по екземпляру mscoree и нетолько
Что вобщемто как бы меня не убеждали ресурсо-неэффективно

Здравствуйте, Edvard Grieg, Вы писали:

EG>Это да однозначно mscoree не грузится статически
EG>И поэтому кажный процесс получает по екземпляру mscoree и нетолько
EG>Что вобщемто как бы меня не убеждали ресурсо-неэффективно

Почитай про домены

Здравствуйте, Silver_s, Вы писали:

S_> Еще память расходуется из-за того что процессы держат многие десятки мегабайт одинаковых стандартных библиотек в памяти.

в случае с DLL это не так,
сегменты кода DLL могут шариться м/у процессами.

а в случае .Net будет именно так, как ты сказал.