Так продолжая традиции же.
Если вас не смущает студия 10, которая 2010, студия 12, которая 2013, студия 13, которую постигла судьба office 13 и студия 15, которая внезапно снова "15" (но на самом деле 20167), то вы приняты
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, flаt, Вы писали:
F>>С VS 2015 и VS 15 постоянная путаница
S>Так продолжая традиции же. S>Если вас не смущает студия 10, которая 2010, студия 12, которая 2013, студия 13, которую постигла судьба office 13 и студия 15, которая внезапно снова "15" (но на самом деле 20167), то вы приняты
Из разряда RSDN Wiki 64-битная Windows — это очень просто!
В список добавить судьбу VC++ 3.0 которая внезапно похожа на 13
И версии компиляторов VC++ в сравнение с версией студии. Было +6, потом +5, а в 15-й пока та же версия как и в 2015
Здравствуйте, RonWilson, Вы писали:
RW>Здравствуйте, _NN_, Вы писали:
_NN>>И версии компиляторов VC++ в сравнение с версией студии. Было +6, потом +5, а в 15-й пока та же версия как и в 2015
RW>Разве в 15 есть С++? Там вроде все вебофрустрированно
Здравствуйте, RonWilson, Вы писали:
RW>Здравствуйте, _NN_, Вы писали:
RW>>>Разве в 15 есть С++? Там вроде все вебофрустрированно
_NN>>С++ никуда не денется _NN>>https://www.visualstudio.com/en-us/news/releasenotes/vs15/vs15-relnotes#cplusplus
RW>я всё жду очередного, когда же MS откажется от не Unicode и придется отказаться от ISAPI Extensions, которые не бывают никакими кроме как ansi.
А как отказаться когда функции представлены в двух вариантах A и W и ещё тонны кода которые хотят компилироваться
Здравствуйте, _NN_, Вы писали:
RW>>я всё жду очередного, когда же MS откажется от не Unicode и придется отказаться от ISAPI Extensions, которые не бывают никакими кроме как ansi. _NN>А как отказаться когда функции представлены в двух вариантах A и W и ещё тонны кода которые хотят компилироваться
declare !UNICODE == deprecated, lots of warnings, "вы конечно дааа, можете их отключить)))", и как с PDK,SDK — просто типа эээ, ну не шмогла)
Здравствуйте, RonWilson, Вы писали:
RW>я всё жду очередного, когда же MS откажется от не Unicode и придется отказаться от ISAPI Extensions, которые не бывают никакими кроме как ansi.
Я конечно тот ещё сварщик, но по памяти ISAPI extensions поддерживают юникод ещё с IIS 6, в IIS 8 даже фильтры можно победить. гуглподтверждает.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, RonWilson, Вы писали:
RW>>я всё жду очередного, когда же MS откажется от не Unicode и придется отказаться от ISAPI Extensions, которые не бывают никакими кроме как ansi. S>Я конечно тот ещё сварщик, но по памяти ISAPI extensions поддерживают юникод ещё с IIS 6, в IIS 8 даже фильтры можно победить. гуглподтверждает.
это слезы, а не поддержка, поверьте, толку нет никакого — они ничего не дали за эти (десятилетие?) чтобы что-то было получше кроме как точки raw bytes, чем unicode и является. Я не жалуюсь, просто Apache httpd дает приблизительно тоже самое, только нужно еще и помнить о worker, fork, event и прочей "прелести" MPM. ЗЫ понять захотелось, глядя на всякие там new WebServer({ return "Aha!" });
Здравствуйте, RonWilson, Вы писали:
RW>это слезы, а не поддержка, поверьте, толку нет никакого — они ничего не дали за эти (десятилетие?) чтобы что-то было получше кроме как точки raw bytes, чем unicode и является. Я не жалуюсь, просто Apache httpd дает приблизительно тоже самое, только нужно еще и помнить о worker, fork, event и прочей "прелести" MPM. ЗЫ понять захотелось, глядя на всякие там new WebServer({ return "Aha!" });
А есть сейчас хоть какая-то потребность в ISAPI?
Разве HTTP modules не перекрывают их полностью?
RW>нет, не перекрывают,
А можно привести какой-то пример, того, что позволяют ISAPI Extension и не позволяют HTTP Modules (managed или native)?
RW>тем более сам asp.net это по сути — isapi extension
Это так, но только для IIS версии 6 и ранее.
Начиная с IIS 7, Http modules вызываются IIS напрямую, минуя механизм ISAPI. По крайней мере это верно для Integrated Mode для Classical, как мне помнится, всё ещё эмулируется работа через ISAPI.
Вот, например, статья ASP.NET Integration with IIS 7, кратко поясняющая суть различий
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, RonWilson, Вы писали:
RW>>нет, не перекрывают, МР>А можно привести какой-то пример, того, что позволяют ISAPI Extension и не позволяют HTTP Modules (managed или native)?
RW>>тем более сам asp.net это по сути — isapi extension МР>Это так, но только для IIS версии 6 и ранее. МР>Начиная с IIS 7, Http modules вызываются IIS напрямую, минуя механизм ISAPI. По крайней мере это верно для Integrated Mode для Classical, как мне помнится, всё ещё эмулируется работа через ISAPI. МР>Вот, например, статья ASP.NET Integration with IIS 7, кратко поясняющая суть различий
Ничего не изменилось, это именно isapi даже по описанию:
The ability to plug in directly into the server pipeline allows ASP.NET modules to replace, run before, or run after any IIS functionality.
Такое поведение характерно именно для ISAPI Filters, не более.
Здравствуйте, RonWilson, Вы писали:
RW>Такое поведение характерно именно для ISAPI Filters, не более.
Только вот модули ASP.Net не являются ни ISAPI Extensions, ни ISAPI Filters.
А те библиотеки, которые являются, т.е aspnet_filter.dll и aspnet_isapi.dll для обработки не используются и даже не загружаются (если только не прописана явная загрузка ASP.Net Filters)
И всё же хочется понять,
что позволяют ISAPI Extension и не позволяют HTTP Modules (managed или native)?
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, RonWilson, Вы писали:
RW>>Такое поведение характерно именно для ISAPI Filters, не более. МР>Только вот модули ASP.Net не являются ни ISAPI Extensions, ни ISAPI Filters.
хотелось бы подробностей — чем они тогда являются, в приведенной статье ничего такого нет
МР>А те библиотеки, которые являются, т.е aspnet_filter.dll и aspnet_isapi.dll для обработки не используются и даже не загружаются (если только не прописана явная загрузка ASP.Net Filters)
Эти dll скорее всего вообще к .net 1.1 относятся, могу уточнить, когда время появится в сорцах IIS
МР>И всё же хочется понять, МР>
МР>что позволяют ISAPI Extension и не позволяют HTTP Modules (managed или native)?
ничего принципиально разного не должно быть, я не спорю, просто кому они нужны?
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, RonWilson, Вы писали:
RW>>Такое поведение характерно именно для ISAPI Filters, не более. МР>Только вот модули ASP.Net не являются ни ISAPI Extensions, ни ISAPI Filters.
поменялось только то, что помимо callback есть еще куча мутотени по обвязке этого сырого добра в интерфейсы, вот и всё.
МР>И всё же хочется понять, МР>
МР>что позволяют ISAPI Extension и не позволяют HTTP Modules (managed или native)?
в принципе, это и есть слезы, по сути — обертка над callback фильтра или расширения, только нафиг оно нужно, удобнее с *_block рабоать? те, кто пишут isapi и так знают как работать с ним
To create a custom HTTP handler, you create a class that implements the IHttpHandler interface to create a synchronous handler. Alternatively, you can implement IHttpAsyncHandler to create an asynchronous handler. Both handler interfaces require that you implement the IsReusable property and the ProcessRequest method.
Здравствуйте, RonWilson, Вы писали: RW>поменялось только то, что помимо callback есть еще куча мутотени по обвязке этого сырого добра в интерфейсы, вот и всё.
Ну т.е. вы согласны, что в IIS handlers и modules к ISAPI отношения не имеют. RW>в принципе, это и есть слезы, по сути — обертка над callback фильтра или расширения, только нафиг оно нужно, удобнее с *_block рабоать? те, кто пишут isapi и так знают как работать с ним
Не понял о какой обертке вы говорите. В Integrated Mode (впрочем, похоже, как и в Classic) никакого фильтра или расширения не вызывается (т.е. не вызывается ни HttpFilterProc, ни HttpExtensionProc).
Call Stack
На вопрос почему от ISAPI отказались в пользу другого API, сказать ничего не могу.
