- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
[WebMethod]
public PackageHoldResult RegisterHold(
string login,
string password,
PackageHoldRequest holdRequest)
{
PackageHoldResult result = new PackageHoldResult();
result.ResultCode = 0;
try
{
// ...
}
catch
{
result.ResultCode = (int) PackageHoldRequestResultCode.InternalError;
}
return result;
}
Follow us!
Злое наследие WinAPI, сломавшее мозги многим поколениям программистов. Коды возврата.
можно подумать, в позиксовых api эксепшены кидают)))))
Вы предлагаете выкинуть весь существующий софт под posix и win32api, и написать с ноля?
В конце концов, сейчас винапи это прокси для нативапи, и никто не умер. Предоставить новые, удобные интерфейсы и нарисовать ими слой абстракции для недопрограмм прошлого. Программисты только спасибо скажут.
Если на C++, то например есть MFC же, и еще куча всего
Там есть std::exception.
Мне не нужна обертка над винапи.
сделать C++ обертку прямо вокруг nativeApi, а win32api объявить депрекейтед? Вот драйверописатели-то обрадуются.
Или вы хотите nativeApi тоже сделать на C++?
Я предлагаю написать нормальный апи и реализовать нативапи на нем, как уже сделали для винапи, реализовав его на нативапи.
Писать на С++ проще, чем на чистом С. Никаких тебе __try __except и прочих низкоуровневых вещей, если хочешь - пишешь __asm и выворачиваешься.
Драйверы это single points of failure, поэтому их нужно писать как можно более производительным.
Ящитаю, главное - это удобство пользователя (т.е. мучения кодера, зато скорость драйвера), и только на втором месте - удобство программиста (отсутствие мучений, зато тормоза, ага).
Не ленитесь.
И я вообще не понимаю, зачем нужны исключения на таком уровне. Исключения это больше энтерпрайз, чтобы можно было получать красивую, развёрнутую ошибку. А в драйверах этого ничего не надо. Там чёрная работа, копоть.
Там такие же быдлокодеры. И драйвера только выиграют от возможности их написания на более высокоуровневых конструкциях.
Пользователю будет крайне неудобно, если комп будет тормозить из-за ошибок в драйвере. Лучше использовать более строгий язык для их избегания.
С другой стороны, у C++ на каждый компилятор свой хитро вы*банный mangling, и очень сложно делать биндинги к другим языкам.
А ограничивать апи платформы возможностью использовать только один конкретный язык - гнилой шаг.
Таким образом, АПИ на си, пусть си и устарел, -- лучшее на сегодняшний день решение.
Вообще же сейчас редко кто пишет на винапи, в основном используют обёртки (которые созданы легко и непринуждённо благодаря универсальности C API), и проблемы реально никакой нет.
Вы троллите?
Интерфейс операционной системы должен быть по своему призванию как можно более универсальным.
Так вот, не каждый язык объектный. Не каждый язык аспектный. Более того, в разных объектных языках может быть разная, несовместимая меж собой "объектность". Попытка скрестить между собой разные платформы привела бы к костылям, тормозам. И это отнюдь не спички. В нативном АПИ обычно никто не пишет, используются разные фреймворки (legacy ли, кросс-платформенности ради ли). Поверх этих фреймворков обычно пишутся ещё свои какие-то минифреймворки. В совр. приложениях множество слоёв абстракции, которые замедляют выполнение. Так зачем же изначально прибавлять ещё один ненужный слой абстракции, без которого можно обойтись?
А чего вам не хватает в ВинАпи, собственно говоря? Там есть объекты. Они эмулируются семантически. Там есть метаинформация.
"Голый си" это ведь на деле просто синтаксис. В винапи есть и объекты, и методы этих объектов, и полиморфизм (мы можем вызывать функцию на хендлы разных типов), и инкапсуляция (мы не можем прочесть внутреннюю структуру, использующуюся ОС), и своего рода классы (напр., классы окон). Наследование эмулируется аггрегацией, обёртками.
Проблема высосана из пальца.
И чё? В совр. ВИНАПИ, как и errno в совр. POSIX'ах, потокобезопасны
Вы об objectManager и хэндлерах?:)
На самом деле ООП это ведь просто следующий шаг развития модульного программирования на чистых сях. Концепции в нем заложены те же самые. Просто вместо object->method() там method(link_to_object), вместо приватных методов -- статические итд..
В принципе на си можно писать почти такой же красивый код, как и на языках с поддержкой ооп, просто он будет несколько более громоздком и не таким читаемым.
Так что мнения некоторых товарищей, дескать "винда глючная потому что на с, а если переписать на с++ -- станет стабильной и быстрой" напоминают мне маркетинговые статьи про .net от microsoft о том, что до появления гарбич коллекторов -- все программы текли памятью, и написать рабочий код на языке без автоматического управления кучей -- невозможно.
Рабочий? Легко. Надёжный? Сложнее.
да, не так удобно, как привычно, но задача того требует.
и наоборот, писать юзеро-интерфейс с кнопачками и проч, на ассемблере - тоже точно такой идиотизм. Нет, то есть, никто не запрещает, но тут вряд ли достоинства низкоуровневого языка оправдают его недостатки
как то так
п.с. надеюсь, не будете кричать, что, мол, сегодня компы такие мощные, что можно за производительностью не гоняться?
Если драйвер действительно тормозит - его следует переписать так, чтобы он не тормозил. И это, кстати, не всегда говорит о том, что мы заменяем исключения на коды возврата - иногда выкинуть 1 исключение на миллион прогонов быстрее, чем в каждом прогоне делать условие на недопущения исключения, все зависит от входных данных. А людей, которые задумываются об оптимизации скорости в момент написания программы, следует убивать.
а мне кажется, что именно в случае написания драйверов лучше сразу проверять флаги, чем заряжать целую систему исключений
Если есть реальный код - можно о чем-то говорить, а до той поры любая оптимизация - это то, за что следует убивать.
Однако, видимо, надо пояснить, что оптимизация на на заключительной стадии, "полирования" кода, это не такая же оптимизация, что на более ранних стадиях. Обобщить можно так: оптимизация на какой то стадии - это поиск оптимального решения всех задач этой стадии, с учетом его влияния на последующие стадии.
(например, оптимизация на стадии проектирования есть подготовка нескольких вариантов проекта и выбор из них одного наиболее подходящего, с учетом возможных проблем)
поэтому, с одной стороны, нельзя при написании кода городить хитровыебанные непонятные конструкции, а с другой, нельзя его писать левой ногой, оставляя приведение его в человеческий вид на самое "потом"
А не в винде?
Но когда Ваш алгоритм прост и очевиден -- врядли Вы будете использовать ООП. Врядли Вы будете юзать объекты что бы считать данные в буфер и там их отсортировать, например.
Большинство драйверов (именно драйверов, а не приложений вообще) это именно такие, четкие и понятные алгоритмы.
Опросил устройство. Если оно готово -- считал через IO какие-то данные, положил в определенное место.
Так что профит даже от ООП тут будет не велик.
Это конечно не касается обычных десктопных приложений, которые под час сложнее энтерпрайза.
Что же касается ассемблера, то аналогия не вполне удачна. Во-первых я очень сомневаюсь, что мы с Вами напишем более оптимизированную программу на ассемблере, чем на сях. Потому что мы в любом случае писать будем что бы было читаемо, а не что бы оптимально. А компилятор генерит нечитаемый, но оптимизированный код.
Во-вторых на каждом уровне -- свои абстракции.
Если мне надо вызвать прерывание -- я напишу на асме: это быстрее и проще. Если мне надо оперировать массивами байт -- я напишу на си, потому что я не хочу думать о регистрах. Если мне надо оперировать понятием "пользователь" и "его покупки" -- я лучше напишу на java (например), потому что мои понятия ложаться в объекты, а не в массивы и не в прерывания или регистры.
Ничто не мешает мне сделать C++ обертку вокруг кода, вызывающего прерывание, и получить в итоге объект, и вызывать у него метод -- но это оверхед.
Так вот драйверы работают на уровне массивов байт (чаще всего, не всегда конечно). Потому си для них ближе и роднее в большинстве случаев.
Мне трудно представить себе драйвер, где во всю юзаются паттерны Observer или Visitor например.
Глупость вместо DrawPixel писать driver->DrawPixel, лишь бы вот чтобы для галочки был ООП.
Вы не знаете? Ну как пример, дотнетовские классы даже кидают исключения, хотя экспортируются из длл'ок.
Управляемые классы (что-то типа дотнетовскх) уже используются для написания большинства частей сверх надёжных, но пока эксперементальных ос и их драйверов. Такая система с трудом способна упасть при падении драйвера. Счастье админам. Сейчас падающий или зависший драйвер крашит систему. Пример тому эксперементальная ось Microsoft Singularity. Некоторые ей пророчат замену Win 7ки через 5ку лет. Сингулярити - не единственный подобный проект, развиваемый в данный момент.
И что будет например, если драйвер обратится к выгруженной памяти?
Возможно, подгрузит, если в данном контексте это допустимо или нагенерит исключений. Это уже все равно не важно, если уже не остановить. Драйвер упадёт, система останется стоять, а не ляжет в бсод.
А вот обращение к указателю на мусор - там принципиально практически не возможно написать.
Единственная проблема - DMA. Только с её помошью можно испортить память. Хотя и это частично там обезопасили.
а можно пруфлинки?
>>Возможно, подгрузит, если в данном контексте это допустимо или нагенерит исключений.
Обычно подгружать нельзя, ибо на этом interrupt level не разрешена смена конктекста...
>>Драйвер упадёт, система останется стоять, а не ляжет в бсод.
вообще-то bsod запускается специально, потому что считается что упавший драйвер может натворить дел (например заглючил драйвер ntfs и снес пол диска). Винда специально врубает bsod (ф-я есть в nativeapi), так что это никак не связано с тем, написан код на C или на Vb.NET :)
>>А вот обращение к указателю на мусор - там принципиально практически не возможно написать.
да, я вкурсе как работает CLR. Но повторюсь: bsod бывает не только от указателя на мусор (хотя gpe конечно может случится), а еще от запрещенных действий кого-то на нулевом кольце защиты, приведших например к исключению (со стороны процессора).
Так что посыл "переписали с С на C# и сделали систему без бсодов, переживающую падение любого драйвера" звучит как маркетинговое ляля для меня)
И потому один конкретный драйвер не может испортить память другого драйвера.
Таким образом ошибки, связанные с загаживанием чужой памяти (которая общая на все kernel-mode процессы -- от ядра до драйверов) в ней отсутствуют.
Но это не убирает проблему упавшего драйвера жесткого диска, при котором система просто по правилам безопастности должна будет лечь в бсод, например
тоесть для этой ос надо разработать новый хардвер с прошитым туда CLR? какой версии?
получается, что безопасность системы определяется реализацией менеджера среды выполнения. интересно, много ли его кода можно отправить в тутошний раздел си шарп? )
Всякие - это все?
Вы в шарпе не профи, потому что слишком просто?