Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
многопоточность, управление процессами, объекты ядра Windows и т. п.,
если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?


Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
Она случаем уже не виртуальная .NET машина?

Начинаем обсуждать.

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

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

Если не даун, то знать нужно... хотя бы для общего развития

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

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

НУЖНО!

А>Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
А>Она случаем уже не виртуальная .NET машина?

Мы бету 2 ставили кажется летом. Framework 1.x и 2.0 там лежит, но виртуальная машина — вроде нет.


А>Начинаем обсуждать.

А что тут обсуждать-то?

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

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

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

Тем не менее, никто не мешает работать над классом задач, где без этих знаний можно обойтись.

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

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

Выделенное вовсе не обязательно. ИМХО, гораздо важнее для прикладного программиста знать математику, например.

Здравствуйте, ghecko,

А>>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

Знать не нужно, а важно. Тогда не возникнут вопросы:

Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
Она случаем уже не виртуальная .NET машина?

Почувствуёте разницу:
Если же использовать WinAPI — нужно это не знать, а понимать.

Хотя может я и не прав — вроде про это знаю, но на .NET что-то толковое не скоро смогу реализовать . На первом этапе это второстепенные вещи.

G> Выделенное вовсе не обязательно.

AFAIK мьютексы — объекты ядра.

G>ИМХО, гораздо важнее для прикладного программиста знать математику, например.

Зачем? (ну кроме элементарной арифметики и логики — это ИМХО обязательно)
Подрабатывал криптоаналитиком, математику знаю плохо (мои оценки 5 говорят лишь об уровне чуть выше среднего).

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

GN>Здравствуйте, ghecko,

А>>>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>>>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>>>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

GN>Знать не нужно, а важно. Тогда не возникнут вопросы:
GN>

Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
GN>Она случаем уже не виртуальная .NET машина?

И почему же они не возникнут?

GN>Почувствуёте разницу:
GN>Если же использовать WinAPI — нужно это не знать, а понимать.

В конексте вопроса знать == понимать, как мне кажется.

GN>Хотя может я и не прав — вроде про это знаю, но на .NET что-то толковое не скоро смогу реализовать . На первом этапе это второстепенные вещи.

G>> Выделенное вовсе не обязательно.

GN>AFAIK мьютексы — объекты ядра.

Но и без знания того, как они там с ядром взаимодействуют не помешает их применять...

Не отрицаю, что для общего развития знать болшн полезно, чем меньше Но на кой знать ASP.NET програмеру как там работает ядро? Нафиг не надо

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

GN>>Знать не нужно, а важно. Тогда не возникнут вопросы:
GN>>

Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
GN>>Она случаем уже не виртуальная .NET машина?

G> И почему же они не возникнут?

Существует огромное количество софта, который использует все эти мютексы и т.п. Зачем пользователям (==кормильцам MS) нужна система, где всё это не будет работать?

G> В конексте вопроса знать == понимать, как мне кажется.

Я стараюсь разделять эти слова. Знать — просто прочитать, что wsprintf нужно передать строчку-формат и т.д. А понимать — это когда учитываешь, что одним из агрументов будет строка пришедшая по инету, и поэтому пишешь другой wsprintf сам.

GN>>AFAIK мьютексы — объекты ядра.

G> Но и без знания того, как они там с ядром взаимодействуют не помешает их применять...

Не мешает. Но двусмысленность возникает — объекты ядра не нужны, а некоторые объекты ядра нужны .

G> Не отрицаю, что для общего развития знать болшн полезно, чем меньше Но на кой знать ASP.NET програмеру как там работает ядро? Нафиг не надо

Ну так и не о ядре речь, а о подсистеме Win32. .NET, по большому счёту, не больше чем враппер вокруг этого. Ограничения базового АПИ так или иначе будут отражены на любых врапперах вокруг врапперов.

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

GN>Ну так и не о ядре речь, а о подсистеме Win32. .NET, по большому счёту, не больше чем враппер вокруг этого. Ограничения базового АПИ так или иначе будут отражены на любых врапперах вокруг врапперов.

Это если обертка тупая. Однако обертка, помимо оборачивания, может содержать и собственный функционал. Например в .NET WinForms.

Здравствуйте, AndrewVK,

GN>>Ограничения базового АПИ так или иначе будут отражены на любых врапперах вокруг врапперов.

AVK>Это если обертка тупая. Однако обертка, помимо оборачивания, может содержать и собственный функционал. Например в .NET WinForms.

А последняя вызывает сразу функции из win32k.sys в обход user32.dll и ntdll.dll? Тогда это очень круто, но думаю это не так.
По поводу функционала, который делает что-то своё, не имелось ввиду. Этот функционал к базовому АПИ отношения может и не иметь совсем, тогда и ограничения не унаследует.
Но возьмём примитивную операцию — запись файла. Ну никакими наваротами NET не запишет файл быстрее на диск, чем это позволит сделать NT.

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

GN>Здравствуйте, AndrewVK,

GN>>>Ограничения базового АПИ так или иначе будут отражены на любых врапперах вокруг врапперов.

AVK>>Это если обертка тупая. Однако обертка, помимо оборачивания, может содержать и собственный функционал. Например в .NET WinForms.

GN>А последняя вызывает сразу функции из win32k.sys в обход user32.dll и ntdll.dll? Тогда это очень круто, но думаю это не так.
GN>По поводу функционала, который делает что-то своё, не имелось ввиду. Этот функционал к базовому АПИ отношения может и не иметь совсем, тогда и ограничения не унаследует.
GN>Но возьмём примитивную операцию — запись файла. Ну никакими наваротами NET не запишет файл быстрее на диск, чем это позволит сделать NT.

Все, что ты говоришь совершенно правильно. И узнавать такие вещи стоит, если есть желание. Только вот инетересно узнать, как часто .NET программисты в работе используют WinAPI напрямую? К тому же, как я понимаю, цель .NET какраз в том, чтобы освободить прикладника от этих заморочек. Тоесть, все эти знания нужны .NET программисту не больее чем для, как выше было сказано, общего развития.
Другое дело, что если мы любим свою профессию и сичтаем себя образованными людьми, то наверное нужно иметь представление о работе системы, под которую мы пишем ПО
Хотя .NET програмисты пишут уже не под Win а под .NET, в идеале.

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

AVK>>Это если обертка тупая. Однако обертка, помимо оборачивания, может содержать и собственный функционал. Например в .NET WinForms.

GN>А последняя вызывает сразу функции из win32k.sys в обход user32.dll и ntdll.dll?

Нет.

GN>По поводу функционала, который делает что-то своё, не имелось ввиду. Этот функционал к базовому АПИ отношения может и не иметь совсем, тогда и ограничения не унаследует.

Еще раз — посмотри на винформс. С одной стороны это обертка над user32.dll и commctl32.dll, но с дургой стороны она куда более функциональна.

GN>Но возьмём примитивную операцию — запись файла. Ну никакими наваротами NET не запишет файл быстрее на диск, чем это позволит сделать NT.

Зато она позволит при записи, к примеру, преобразовывать кодировку, чего Win32 API не умеет.

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

GN>>Но возьмём примитивную операцию — запись файла. Ну никакими наваротами NET не запишет файл быстрее на диск, чем это позволит сделать NT.
AVK>Зато она позволит при записи, к примеру, преобразовывать кодировку, чего Win32 API не умеет.
Это уже не запись, а обработка данных перед записью. Функции записи WinAPI и не должны это уметь. Это не их работа. Какое отношение имеет преобразование кодировки (т.е. операция над данными) к размещению этих данных на неком носителе?

Здравствуйте, AndrewVK,

AVK>Еще раз — посмотри на винформс. С одной стороны это обертка над user32.dll и commctl32.dll, но с дургой стороны она куда более функциональна.

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

GN>>Но возьмём примитивную операцию — запись файла. Ну никакими наваротами NET не запишет файл быстрее на диск, чем это позволит сделать NT.

AVK>Зато она позволит при записи, к примеру, преобразовывать кодировку, чего Win32 API не умеет.

Это опять же улучшение функциональности\гибкости. Вполне логично — добавили код не просто для весу. Но это всё абстрактные величины. Есть же вполне конкретные, которые можно взять и измерить в цифрах. И если мерить цифры для базового API и для надстройки над ним, то цифры во 2м случае будут всегда не лучше (не в смысле "хуже", а в смысле "равны или хуже").

Захотел Вася Пупкин создать 20000000000000000000000000 каких-то там штучек в NET, ан нет. Но это не ограничение NET. Нужно спуститься уровнем ниже. И это не ограничение WinAPI или даже ядра. Это уже ограничение самого низкого уровня — x86. Это сильно утрированный пример, но я лучше видимо не смогу придумать причины, зачем нужно программисту на NET знать о регистрах процессора .

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

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

Да хоть и никогда . Ведь по сути — какая разница, вызываем ли мы одно АПИ, или вызываем второе, которое всё равно вызывает первое.

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

Одна из целей любого языка — освободить от каки-то заморочек. Если бы это кому-то удалось, то вероятно остался бы только один язык. И Джоэль Спольски не писал бы Назад, к основам.

G> Другое дело, что если мы любим свою профессию и сичтаем себя образованными людьми, то наверное нужно иметь представление о работе системы, под которую мы пишем ПО

Я практически по этой же причине изучаю NET. Мне это совершенно не нужно для работы, но уверен, что только выиграю от этого.

G> Хотя .NET програмисты пишут уже не под Win а под .NET, в идеале.

Так же и программисты на С++ в идеале пишут под С++, но почему-то в конечном счёте этот идеал превращается в бесконечные директивы сопроцессора и всё равно где-то это не будет работать .

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

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?
Конечно же надо. Давай разберемся:
1. Мьютексы. Дотнет не предлагает тебе никаких средств межпроцессной синхронизации. А если предложит, то все равно они будут построены вокруг мьютексов. А, стало быть, тебе все равно придется понять, что такое мьютекс — ведь неважно, как он называется, важно, как он себя ведет. Ну либо ты откажешь себе в умении писать решения, состоящие из согласованно работающих процессов.
2. Именованные каналы. Опять же, именованный канал — это средство межпроцессно/межмашинной коммуникации. Ты никуда от него не денешься. Возможно, фреймворк и даст тебе какие-то обертки вокруг пайпов, но ты не сможешь ими эффективно пользоваться, не понимая, что такое пайп.
3. Почтовые ящики — та же фигня.
4. Управление процессами. Если ты не хочешь управлять процессами, то можешь не изучать. Хотя я не понимаю паники вокруг изучения четырех функций API и стоящей за ними модели. Причем если на функции можно забить, то без понимания того, что такое процесс, и чем он отличается, к примеру, от потока, программировать под винду крайне сложно.
5. Объекты ядра.
Это ты что имеешь в виду? Объектов ядра довольно много. Все они нужны. Можно позволить себе не ковыряться в их внутренней структуре. Но представлять себе, про что там всяие Waitable Timer, крайне желательно. А то все это напоминает желание играть в футбол, но безо всех этих мячей и бутсов.

А>Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
Все актуально. И будет актуально в следующей версии после висты. И даже когда выйдет Windows 2050, ты сможешь покряхтывая, сказать что-то вроде: "А-а, так это ж они взяли старые добрые хэндлы, и обозвали технологию по комбинированию их XMAglue. Значит, ограничение в 2^32 все еще сохранилось. Ха-ха.". Или, наоборот: "О, наконец-то они убрали эти дурацкие костыли, придуманные еще в десятом году".

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

AVK>>Еще раз — посмотри на винформс. С одной стороны это обертка над user32.dll и commctl32.dll, но с дургой стороны она куда более функциональна.

GN>Под ограничениями я не подразумеваю уменьшение функциональности.

Тогда что ты под этим подразумеваешь?

Здравствуйте, AndrewVK,

GN>>Под ограничениями я не подразумеваю уменьшение функциональности.

AVK>Тогда что ты под этим подразумеваешь?

Например, ограничение на количество GDI объектов в системе. Или количества потоков.

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

GN>Например, ограничение на количество GDI объектов в системе. Или количества потоков.

Это тоже функциональные ограничения. Кроме того, например ограничение на количество потоков в дотнете вполне преодолимо, поскольку нет однозначной связи между логическим и физическим потоком и вместо физического можно прикрутить те же файберы.

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

GN>>Например, ограничение на количество GDI объектов в системе.

AVK>Это тоже функциональные ограничения.

Значит я не понимаю, что такое функциональные ограничения .
ИМХО это ограничение количества доступных ресурсов.