Писать никто не заставляет — но читать-то приходится.
Ну, а проще или нет — это субъективно (см. мой комментарий ниже).
Тем более, что мне прежде всего требуется понимание — надеюсь, код библиотеки уже отладили, без меня ;-)
А что до отладки, то лично я в давние времена привык к тому, что есть закрытый код, исходники которого просто недоступны. Например — системные вызовы Windows, да и код IIS — тоже. Поэтому выработал способы борьбы, работающие и в этих условиях (при наличии хорошей документации, конечно): проверка параметров перед вызвовом закрытого кода и сравнение результата с ожидаемым, установка точек останова на любой свой код функции обратного вызова и т.д.
Однако для этого требуется хорошая документация. И у MS она тогда уже была. Но это все — чисто мои привычки.
Но в некие совсем уж древние времена (Windows то ли 3.0, то ли 3.1) с документацией от MS было сложнее (по крайнейе мере, в России), так что даже как-то пришлось в отладчике смотреть, как именно возвращаются значения из процедуры диалога в функцию его вызова: там фиксированный набор значений возващался напрямую (недокументированно), а большинство — через поле в структуре диалога (документированно).
По-моему, тут существенно, для какой области предназначены эти технологии.
Delphi была, с одной сторны, очень хороша для разработки приложений для десктопа под Windows (среди перечисленных вами к этой категории отностится только VB) в том числе — и для работы с БД, причем как файловыми, так и по схеме клиент-сервер, с другой — достаточно универсальна, чтобы ее можно было использовать для разработки для платформы Windows в целом: на ней можно было делать и сетевые программы, и системные службы, и даже программы для веб-сайов под IIS — то, что ныне именуется «back end» (а вот VB такой универсальностью не обладал). Впрочем, в этих, остальных? областях Delphi, на мой субъективный взгляд, ничуть не выигрывала у того же Visual C++.
А сейчас разработка приложений для десктопа — она, мягко говоря, не сильно востребована. Впрочем, и для этой области в современных (условно) средствах разработки есть, по крайней мере, одна сравнимая альтернатива — Windows Forms в .NET.
Другое дело, что в более актуальных для современности областях разработки, таже схожего назначения — например Web, front-end PWA, решающие идейно примерно те же задачи, что и десктопные клиенты лет 20 назад — ничего подобного Delphi по простоте испоьзования («накидать компонентов на форму»)и, одновременно, универсальности лично я не знаю. Впочем, и задачи у фронт-энда — они посложнее чем в десктопной разработке 20-летней давности: тут и необходимость поддержки страниц разного размера (ведь формы — они чаще были фиксированные по размеру), и далеко не идеальная надежность канала связи, и отсутствие стандартного API для доступа к серверу, и т.д.
PS А вообще, «проще/сложнее писать» — это IMHO характеристика сильно субъективная, зависящая от пишущего, его опыта и его привычек.
Ну, не знаю, не знаю. Лично для меня стиль написания программ в современном .NET (в частности — исходника ASP.NET Core) — с цепочками вызовов нескольких методов подряд через точку (да еще и со сменой типа объекта в процессе (как, например при конфигурировании Options IServiceCollection где-то в середине цепочке легким движением руки превращается в OptionsBuilder), кучей лямбд (причем — не просто коротких типа параметр=>результат, а лямбд с фигурными скобками или лямбд внути лямбд), и широким использованием возможностей скрывать типы используемых переменных (var, параметры лямбда-функции) — выглядит сильно сложнее, чем стиль того же .NET, применявшийся 10 лет назад. По крайней мере, исходные текты от MS мне стало читать заметно сложнее.
PS Пардон, первый вариант был ответом не вам, я перемстил его в нужное место.
Код Win3x был дизасемблирован и весьма подробно разобран Мэттом Питреком (книга эта была переведена и на русский, если кому это интересно — могу поискать в книжном шакафу и сообщить выходные данные: она у меня есть).
В NT до версии 4.0 графическая подсистема была реализована в процессе пользовательского режима (аналогично современной ей X Windows System), а потому специального API ядра для нее не было.
Дык, это у нее был минимально требуемый объем памяти (если говорить о 2.0, которая «лучшая Windows, чем Windows» — это фраза из рекламы IBM).
А Windows 3.1 минимально требовала 2МБ, если говорить о расширенном режиме — т.е. когда она работала как ОС, полностью забирая на себя управление процессором, а ядро DOS при этом работало под ее контролем в режиме V86.
А в стандартном режиме, когда Windows работала как настройка над DOS с помощью DOS Extender, минимальным требованием было вообще 1МБ.
Скорость отрисовки зависела тогда сильнее не от скорости процессора или памяти, а от видеоадаптера: тогда в них как раз пошли в массы средства аппартного ускорения рисования графических примитивов — всяких линий, фигур, заливка цветом и т.д. — в изначальных EGA или VGA ничего такого и близко не было, там программы должны были самостоятельно каждый пиксель в фрейм-буфер писать. Да ещё и в несколько проходов: в EGA/VGA в 16-цветных режимах каждый из 4 бит пиксела находился на своей «плоскости» (странице фрейм-буфера отображаемого в память на одни и тот же адреса), для переключения доступа которым надо было писать в регистр видеоадаптера. И — от драйвера видеоадаптера, который транслировал вызовы GDI в команды для видеоускорителя. Так что наблюдаемая разница между Windows и OS/2 могла быть связана с этим — с тем, что видеоадаптеры на сравниваемых машинах были разными.
Безобразия по поводу двукратной отрисовки в стандартных программах или в своих, написанных чисто на C, я не наблюдал, даже на самом медленном из используемых компьютеров — с EGA+1МБ памяти. Видать, это была особенность именно Delphi: Windows ничего из нарисованного (в том числе — и элементы оформления окна) в памяти не буферизовала (некуда было), поэтому по команде из программы все перерисовывалось заново: одна команда — одна перерисовка, две команды — две перерисовки.
Короче, OS/2, насколько я могу судить, была тогда совершеннее Windows, но — с бОльшими требованиями к памяти, и при тогдашних ценах на память разница была весьма существенна.
Немного не согласен с выделенными моментами. Такой функционал невозможно реализовать с помощью механизма исключений, используемого в языках программирования. Здесь уже нужно опускаться до уровня WinAPI.
Я как раз и имел в виду Win32 API. Потому что вел разговор про управление памятью на уровне ОС.
И проблемы именно для игроделов возникают уже на этом уровне.
В Windows есть состояние памяти reserved, которая как раз предназначена для этих самых целей — резервирования адресного пространства без выделения под него памяти. При обращении к такой памяти, естественно, возникнет исключение, но его несложно перехватить, выделить память под это обращение и вернуть управление в ту точку, в которой произошло обращение к памяти, для повторного выполнения — это стандартная функциональность обработки исключений. Техника эта была описана в древней (ещё про начальную версию NT) книге Джеффри Рихтера про Win32.
Игроделы могут не использовать это, потому что выделение памяти — далеко не мгновенная операция, можно в интервал отрисовки кадра не успеть выполнить.
Вот буквально как вчера мой jupyter notebook с python+Pandas выжрал 55Gb (из 64), и дальше отказался работать
Тут надо смотреть для начала, откуда именно он память выжрал. В Windows у ядра есть неподкачиваемый пул памяти, которая никогда не сбрасывается на диск (потому что используется той частью ядра, которая не может использовать виртуальную память), и если он заполняется (например, утекет память в драйвере или остаются незакрытые описатели потоков в процессе), то система нормально работать уже не может. Смотреть можно много откуда — в Диспетчере задач, например.
В 32-битных Windows Server, в которых размер этого пула был ограничен сотнями мегобайт, утечка памяти из неподкачиваемого пула была нередкой проблемой. В 64-битных системах проблема возникает реже, но пару раз видел.
Если у вас дело в этом, то источник проблемы найти можно: могу рассказать, как, или самому найти не сложно по ключевому слову poolmon (это утилита, которая показывает, чем знаяты пулы памяти ядра)
На самих перфокартах карандашом писали текст. Потом появились перфораторы с надпечаткой, это было намного удобнее. В качестве редактора выступали руки: из колоды изымались ненужные операторы и вкладывались на нужные места свеженапечатанные.
Избаловали вас ;-)
Я «вошел в IT» на несколько лет раньше вас (судя по вашему году рождения), и меня тогдашние суровые программисты предыдущего поколения обучали (и почти обучили тогда) читать перфокарты без надпечатки (и никакого карандаша!) и редактировать их с помощью лезвия (вырезались перфорации, где надо) и отходов-«квадратиков» из-под перфоратора (ими затирались перфорации, где не надо). Потому что это сильно ускоряло повторный прогон программы — не надо было стоять в очереди в перфораторную. Так что профессионалу-программисту тех времен полагалось для хорошей производдительности иметь при себе комплект из лезвия от безопасной бритвы и спичечного коробка с «квадратиками».
А потом появились дисплеи ЕС7906, а затем — ЕС7920, были написаны системы ввода заданий с них (помню «Примус»), и это старое искусство обращения с перфокартами стало не нужно.
Уязвимость активирует на шлюзе NAT переадресацию входящего подключения из интернета к шлюзу на выбранный злоумышленником порт вашего телевизора во внутренней сети. После это на телевизор к этому порту может долететь снаружи то, что захочется злоумышленнику.
Трансляция настраивается с использованием шлюза прикладного уровня (ALG) на шлюзе NAT, который нужен для работы протокола H.323. Именно в этом протоколе можно указать необходимость входящео подключения на другое устройство (для переадресации звонка). Есть и другие протоколы (FTP, например), для работы которых их ALG настраивает прием входящего подключение на шлюзе NAT, но для остальных, кроме H.323, возможна настройка переадресации подключения только на тот же хост внутренней сети, который инциировал настройку.
О чем спорим? О том, что в жизни приходится отклоняться от всей этой замечательной реляционной теории (иногда — сильно) — я не спорю, я тут с вами согласен.
Но вот выдавать нужду за добродетель и пропагандировать как универсальный такой подход, что надо писать на SQL поперек его идеологии языка декларативного программирования — с этим не согласен.
PS По то, что непосредственно у авторов статьи по ссылки не было возможности менять что-то в базе — это я понял. Но такая возможность была у других, тех кто базой владеет (а у авторов — убедить владельцев в пользе этого). Добавление индекса к таблице, в отличие от изменения запроса — операция почти бесплатная и почти не влияющая на работу других приложений (но опять-таки, почти: обновление добавленного индекса добавляет нагрузку, например).
Потому и написал — отказались (и не написал — кто).
Ну, я именно по этому поводу и написал — жизнь сложнее.
В плане SQL я с этим столкнулся ещё лет двадцать назад, когда мы обнаружили, что планировщик запросов Interbase 4.0 (была такая СУБД, в те времена весьма популярная, ибо шла в комплекте с Delphi) совершенно не умеет оптимизирвать запросы с LEFT OUTER JOIN, скатываясь в последовательную выборку по левой таблице (естественно — самой большой). Нам тогда пришлось разделить запрос на два (благо OUTER JOIN был нужен ровно один) и объединять их через UNION.
Но вот пример по ссылке — это то, как делать не надо (ну, если вообще есть возможность так не делать, конечно ;-), ещё раз повторю: жизнь сложнее ): сначала там отказались от использования совершенно стандартной возможности СУБД — индекса, а потом героически написали фактически свой планировщик запроса на SQL, чтобы получить хоть сколь-нибудь эффективную выборку на тех возможностях, что у них остались. Ну да, не спорю: для написания планировщика запроса продумывать последовательность действий, естественно, необходимо. Но такие задачи — редкость (мягко говоря): чаще всего хватает возможностей планировщика, который уже есть в СУБД.
Я даже понимаю (вроде бы) резоны владельца СУБД, куда пишется лог — почему он мог запретить создавать индекс: обновление индекса может быть затратным, а новые записи в логи иногда сыпятся так быстро… Но, наверное там надо было бы что-то поменять в архитектуре.
К примеру, хранение лога, вообще говоря, вовсе не требует такой сложной штуки, как СУБД. В частности, для задачи последовательной записи лога и бинарного поиска в нем номеру записи хватило бы применения такого артефакта древних времен, как «набор данных произвольного доступа с записями переменной длины»: данные совершенно последовательно пишутся в конец лога, а бинарный поиск делается чтением этого набора, открытого с произвольным доступом к записям по их номерам. Когда-то, во времена IBM System/360, поддержка такой штуки опиралась даже на аппаратные возможности самих дисков (CKD Devices). Сейчас со штатной поддержкой такого, конечно, стало сложнее, но даже на базе обычного плоского файла сделать что-то можно — правда, границы записей придется искать самим в программе.
Но ещё лучше бы подошел другой артефакт тех же врмен: «индексно-последовательный набор данных» (который тогда обслуживался утилитой с примечательным именем, которое я помню до сих пор: IEBISAM): данные в нем располагались последовательно в порядке некоего ключа, и записи по этому кючу можно было искать. поэтому для задачи поиска по ключу в виде даты/времени записи он подошел бы лучше. И вот у у этого древнего артефакта есть прямой аналог — clustered index — в современных СУБД, по крайней мере — в некоторых (точно знаю, что есть в MS SQL, но вот за Postgress не скажу). То есть для приема логов в БД создается таблица с первичным кластерным индексом по дате/времени (лучше — с повышенным фактором его заполнения, чтобы не терять зря много места). Запись в нее фактически идет последовательно, без особых потерь на поддержку индекса (разделения блоков дерева там не будет, а поворот, чтобы дерево сбалансировать, может быть отложен и до момента, когда нагрузка снижается). А запрос для выборки по диапазону дат отлично оптимизируется по первичному индексу шатным планировщиком. Вот как-то примерно так можно было бы сделать.
Я бы сказал — статья по духу совершенно не SQLвская.
SQL ведь по своему духу не похож на обычные императивные языки: там надо написать что нужно получить, но не надо(в идеале, жизнь сложнее) описывать как это получить. Поэтому расказывать истории — это IMHO не в духе SQL.
Аналогично с тестированием — тестировать лучше на специально подобранных данных. Для теста стоит завести тестовую БД со специальным наполнением и проверять запрос на ней. Правда, не знаю как там будет интеграцией с используемой IDE — можно ли «не отходя от кассы» сразу увидеть зелененькие огоньки прошедших тестов.
Это IMHO существенно: реальная работа (та, которая «за деньги» и «на дядю»), даже любимая, обычно включает в себя как часть приятную (интересную, любимую), так и неприятную (скучную, нелюбимую) — и делать надо обе части.
Плюс именно любимой работы при этом в том, что те же деньги получаешь за меньший объем делаемой работы, на нелюбимую ее часть — другая часть, любимая, делается для своего удовольствия ;-).
Давно всё работает по ews, типа mapi и прочий rpc для ценителей:)
Ну что вам на это сказать? Подключитесь Outlook'ом к Exchange и посмотрите в логе IIS, через какой виртуальный каталог идет основной обмен. Или при запущенном Outlook вытащите его полное локальное меню (Ctrl+правая кнопка мыши на значке в области уведомлений), выберите там пункт про состояние подключения, и посмотрите, по какому протоколу подключен Outlook к ящику и адресной книге. Если Outlook и Exchange не слишком старые, то там почти наверняка будет MAPI/HTTP.
Да, MAPI over RPC остался, в основном, в прошлом, но MAPI/HTTP — это тоже вариант програмного интерфейса MAPI, только использующий другой транспорт: для кода Outlook работа с ним выглядит практически так же. И это важно, т.к. позволяет повторно использовать всю ту гору кода, которая уже написана.
А EWS в Outlook используется для вспомогательных целей: обмен информацией о занятости, управление оповещениями об отсутствии, получение подсказок от сервера при составлении письма…
Он заменит настольные (win32 и UWP) версии Outlook, Outlook Web Access (OWA) и настольный клиент macOS.
Вот что-то мне, как человеку, профессионально занимающимуся Outlook и Exchange, это кажется сильно сомнительным. Outlook ведь для доступа к Exchange использует проткол MAPI — который проприетарный MS-овский, который весьма тяжелый, но который дает дает возножность доступа ко всем возможностям Exchange (к Exchange Online это тоже относится, не только к Exchange на земле). А ещё MAPI сильно привязан к Windows, потому что базируется на COM. Как это сможет жить на Mac — не представляю. Outlook для Mac, например, использовал не MAPI, а EWS, который доступа ко всем возможностям уже не дает. Ну, а тот же IMAP — да, он стандартный, но он дает доступ тоже только к вещам весьма стандартным.
То, что MS угробит конкурентное преимущество своей технологии ради сомнительных благ унификации — не верится.
Мое мнение: можно (и нужно — ибо необъятное объять нельзя) ограничиться только тем, что упомянуто.
Но я бы ещё после каждого разобранного понятия написал, как оно называется в больших и скучных учебниках — чтобы прокинуть мостик к этим учебникам, чтобы говорить с людьми, которые по ним учились, на одном языке, чтобы слова типа «третья нормальная форма» не ставили в тупик на собеседовании.
Ну-ну, а высокую доступность волшебные феи обеспечивать будут?
По-моему, вы несколько преувеличиваете сложность и дороговизну обеспечения высокой доступности. Поскольку я не специалист по Linux, а потому не могу подробно рассмотреть, как там обстоят дела с этим в нижнем ценовом сегменте, то расскажу про то, что может предложить людям экономным Windows Server во вполне стандартной комплекатции. Это, конечно, не экомом-класс (потому что сама цена на лицензию даже для Standard Edition весьма ощутима), но, по сравнению с ужасами кровавого энтерпрайза, все очень по-божески.
Начнем с отказоустойчивости приложения. Компонент отказоустойчивой (по-русски, точнее, но длиннее — способной обойти отказ, ибо по-английски это failover) кластеризации в эту самую стандартную редакцию встроен уже давно. И для задействования этого средства при написании приложения не нужно делать свой велосипед — достаточно реализовать небольшую DLL для взаимодействия со службой управления кластером. Более того, если приложение позволяет управление собой через COM, то вместо DLL можно ограничиться скриптом на JavaScript (или VBScript). А если приложение реализовано как служба Windows, и настолько просто, что его работоспособность/неработоспособность определяется исключительно по факту того, запущена ли служба, то для использования отказоустойчивой кластеризации можно вообще не писать никакой код: я, например, некогда написал статью про то, как можно сделать потешный (т.е. для развлечений, в бой совать его не надо) кластер DNS на базе стандартной службы из Windows Server. Ну, и для веб-приложений под IIS отказоустойчивая кластеризация тоже возможна (и есть руководство, как это настроить, где-то на сайте Microsoft), хотя для их развертывания в многосерверной конфигурации чаще применяют балансировку нагрузки (в том числе — и встроенную, которая есть в составе Windows Server).
Далее, высокую доступность сети для Windows Server можно обеспечить разными встроеными в него способами. Простейший и самый древний — объединить пару сетевых интерфейсов в виртуальный мост (он понимает STP) и подключить эти интерфейсы к разным коммутаторам, тоже понимающим STP. А кроме этого в Windows Server встроена агрегация сетевых интерфейсов (NIC Teaming) в нескольких вариантах: зависимая и независимая от коммутатора, статическая и динамическая — она тоже обеспечивает устойчивость к отказу сетевого адаптера/кабеля/коммутатора.
С отказоустойчивостью данных, да так чтобы обойтись без единой точки отказа доступа к ним (а не только обеспечить сохранность при отказе диска), если при этом ограничиться чисто Windows Server, немного сложнее. Но и тут вполне можно обойтись без дорогой SAN. Правда, стандартная редакция может предложить только построение на базе нескольких подключенных по iSCSI LUN на недорогих и не отказоустойчивых устройствах хранения (их требуется от 3-х штук) кластерного варианта Storage Spaces, на базе которого уже можно сделать отказоустойчивые виртуальные диски. Решение это несколько неуклюжее и костыльное (т.к. шатно Storage Spaces рассчитан на работу на базе локальных физических дисков), но, в принципе, работоспособное (хотя про необходимую полосу пропускания сети для него забывать нельзя). Но если появляется целесообразность использования более дорогой редакции Datacenter Edition (т.е. если служб становится больше некоего минимума), то в этой редакции есть гиперконвегентный вариант Storage Spaces — Storage Spaces Direct — который можно уже штатно использовать для построения хранилища на локальных дисках серверов без единой точки отказа.
Ну, а проще или нет — это субъективно (см. мой комментарий ниже).
Тем более, что мне прежде всего требуется понимание — надеюсь, код библиотеки уже отладили, без меня ;-)
А что до отладки, то лично я в давние времена привык к тому, что есть закрытый код, исходники которого просто недоступны. Например — системные вызовы Windows, да и код IIS — тоже. Поэтому выработал способы борьбы, работающие и в этих условиях (при наличии хорошей документации, конечно): проверка параметров перед вызвовом закрытого кода и сравнение результата с ожидаемым, установка точек останова на любой свой код функции обратного вызова и т.д.
Однако для этого требуется хорошая документация. И у MS она тогда уже была. Но это все — чисто мои привычки.
Но в некие совсем уж древние времена (Windows то ли 3.0, то ли 3.1) с документацией от MS было сложнее (по крайнейе мере, в России), так что даже как-то пришлось в отладчике смотреть, как именно возвращаются значения из процедуры диалога в функцию его вызова: там фиксированный набор значений возващался напрямую (недокументированно), а большинство — через поле в структуре диалога (документированно).
Delphi была, с одной сторны, очень хороша для разработки приложений для десктопа под Windows (среди перечисленных вами к этой категории отностится только VB) в том числе — и для работы с БД, причем как файловыми, так и по схеме клиент-сервер, с другой — достаточно универсальна, чтобы ее можно было использовать для разработки для платформы Windows в целом: на ней можно было делать и сетевые программы, и системные службы, и даже программы для веб-сайов под IIS — то, что ныне именуется «back end» (а вот VB такой универсальностью не обладал). Впрочем, в этих, остальных? областях Delphi, на мой субъективный взгляд, ничуть не выигрывала у того же Visual C++.
А сейчас разработка приложений для десктопа — она, мягко говоря, не сильно востребована. Впрочем, и для этой области в современных (условно) средствах разработки есть, по крайней мере, одна сравнимая альтернатива — Windows Forms в .NET.
Другое дело, что в более актуальных для современности областях разработки, таже схожего назначения — например Web, front-end PWA, решающие идейно примерно те же задачи, что и десктопные клиенты лет 20 назад — ничего подобного Delphi по простоте испоьзования («накидать компонентов на форму»)и, одновременно, универсальности лично я не знаю. Впочем, и задачи у фронт-энда — они посложнее чем в десктопной разработке 20-летней давности: тут и необходимость поддержки страниц разного размера (ведь формы — они чаще были фиксированные по размеру), и далеко не идеальная надежность канала связи, и отсутствие стандартного API для доступа к серверу, и т.д.
PS А вообще, «проще/сложнее писать» — это IMHO характеристика сильно субъективная, зависящая от пишущего, его опыта и его привычек.
PS Пардон, первый вариант был ответом не вам, я перемстил его в нужное место.
В NT до версии 4.0 графическая подсистема была реализована в процессе пользовательского режима (аналогично современной ей X Windows System), а потому специального API ядра для нее не было.
А Windows 3.1 минимально требовала 2МБ, если говорить о расширенном режиме — т.е. когда она работала как ОС, полностью забирая на себя управление процессором, а ядро DOS при этом работало под ее контролем в режиме V86.
А в стандартном режиме, когда Windows работала как настройка над DOS с помощью DOS Extender, минимальным требованием было вообще 1МБ.
Скорость отрисовки зависела тогда сильнее не от скорости процессора или памяти, а от видеоадаптера: тогда в них как раз пошли в массы средства аппартного ускорения рисования графических примитивов — всяких линий, фигур, заливка цветом и т.д. — в изначальных EGA или VGA ничего такого и близко не было, там программы должны были самостоятельно каждый пиксель в фрейм-буфер писать. Да ещё и в несколько проходов: в EGA/VGA в 16-цветных режимах каждый из 4 бит пиксела находился на своей «плоскости» (странице фрейм-буфера отображаемого в память на одни и тот же адреса), для переключения доступа которым надо было писать в регистр видеоадаптера. И — от драйвера видеоадаптера, который транслировал вызовы GDI в команды для видеоускорителя. Так что наблюдаемая разница между Windows и OS/2 могла быть связана с этим — с тем, что видеоадаптеры на сравниваемых машинах были разными.
Безобразия по поводу двукратной отрисовки в стандартных программах или в своих, написанных чисто на C, я не наблюдал, даже на самом медленном из используемых компьютеров — с EGA+1МБ памяти. Видать, это была особенность именно Delphi: Windows ничего из нарисованного (в том числе — и элементы оформления окна) в памяти не буферизовала (некуда было), поэтому по команде из программы все перерисовывалось заново: одна команда — одна перерисовка, две команды — две перерисовки.
Короче, OS/2, насколько я могу судить, была тогда совершеннее Windows, но — с бОльшими требованиями к памяти, и при тогдашних ценах на память разница была весьма существенна.
Я как раз и имел в виду Win32 API. Потому что вел разговор про управление памятью на уровне ОС.
И проблемы именно для игроделов возникают уже на этом уровне.
Игроделы могут не использовать это, потому что выделение памяти — далеко не мгновенная операция, можно в интервал отрисовки кадра не успеть выполнить.
Тут надо смотреть для начала, откуда именно он память выжрал. В Windows у ядра есть неподкачиваемый пул памяти, которая никогда не сбрасывается на диск (потому что используется той частью ядра, которая не может использовать виртуальную память), и если он заполняется (например, утекет память в драйвере или остаются незакрытые описатели потоков в процессе), то система нормально работать уже не может. Смотреть можно много откуда — в Диспетчере задач, например.
В 32-битных Windows Server, в которых размер этого пула был ограничен сотнями мегобайт, утечка памяти из неподкачиваемого пула была нередкой проблемой. В 64-битных системах проблема возникает реже, но пару раз видел.
Если у вас дело в этом, то источник проблемы найти можно: могу рассказать, как, или самому найти не сложно по ключевому слову poolmon (это утилита, которая показывает, чем знаяты пулы памяти ядра)
Избаловали вас ;-)
Я «вошел в IT» на несколько лет раньше вас (судя по вашему году рождения), и меня тогдашние суровые программисты предыдущего поколения обучали (и почти обучили тогда) читать перфокарты без надпечатки (и никакого карандаша!) и редактировать их с помощью лезвия (вырезались перфорации, где надо) и отходов-«квадратиков» из-под перфоратора (ими затирались перфорации, где не надо). Потому что это сильно ускоряло повторный прогон программы — не надо было стоять в очереди в перфораторную. Так что профессионалу-программисту тех времен полагалось для хорошей производдительности иметь при себе комплект из лезвия от безопасной бритвы и спичечного коробка с «квадратиками».
А потом появились дисплеи ЕС7906, а затем — ЕС7920, были написаны системы ввода заданий с них (помню «Примус»), и это старое искусство обращения с перфокартами стало не нужно.
Трансляция настраивается с использованием шлюза прикладного уровня (ALG) на шлюзе NAT, который нужен для работы протокола H.323. Именно в этом протоколе можно указать необходимость входящео подключения на другое устройство (для переадресации звонка). Есть и другие протоколы (FTP, например), для работы которых их ALG настраивает прием входящего подключение на шлюзе NAT, но для остальных, кроме H.323, возможна настройка переадресации подключения только на тот же хост внутренней сети, который инциировал настройку.
Но вот выдавать нужду за добродетель и пропагандировать как универсальный такой подход, что надо писать на SQL поперек его идеологии языка декларативного программирования — с этим не согласен.
PS По то, что непосредственно у авторов статьи по ссылки не было возможности менять что-то в базе — это я понял. Но такая возможность была у других, тех кто базой владеет (а у авторов — убедить владельцев в пользе этого). Добавление индекса к таблице, в отличие от изменения запроса — операция почти бесплатная и почти не влияющая на работу других приложений (но опять-таки, почти: обновление добавленного индекса добавляет нагрузку, например).
Потому и написал — отказались (и не написал — кто).
В плане SQL я с этим столкнулся ещё лет двадцать назад, когда мы обнаружили, что планировщик запросов Interbase 4.0 (была такая СУБД, в те времена весьма популярная, ибо шла в комплекте с Delphi) совершенно не умеет оптимизирвать запросы с LEFT OUTER JOIN, скатываясь в последовательную выборку по левой таблице (естественно — самой большой). Нам тогда пришлось разделить запрос на два (благо OUTER JOIN был нужен ровно один) и объединять их через UNION.
Но вот пример по ссылке — это то, как делать не надо (ну, если вообще есть возможность так не делать, конечно ;-), ещё раз повторю: жизнь сложнее ): сначала там отказались от использования совершенно стандартной возможности СУБД — индекса, а потом героически написали фактически свой планировщик запроса на SQL, чтобы получить хоть сколь-нибудь эффективную выборку на тех возможностях, что у них остались. Ну да, не спорю: для написания планировщика запроса продумывать последовательность действий, естественно, необходимо. Но такие задачи — редкость (мягко говоря): чаще всего хватает возможностей планировщика, который уже есть в СУБД.
Я даже понимаю (вроде бы) резоны владельца СУБД, куда пишется лог — почему он мог запретить создавать индекс: обновление индекса может быть затратным, а новые записи в логи иногда сыпятся так быстро… Но, наверное там надо было бы что-то поменять в архитектуре.
К примеру, хранение лога, вообще говоря, вовсе не требует такой сложной штуки, как СУБД. В частности, для задачи последовательной записи лога и бинарного поиска в нем номеру записи хватило бы применения такого артефакта древних времен, как «набор данных произвольного доступа с записями переменной длины»: данные совершенно последовательно пишутся в конец лога, а бинарный поиск делается чтением этого набора, открытого с произвольным доступом к записям по их номерам. Когда-то, во времена IBM System/360, поддержка такой штуки опиралась даже на аппаратные возможности самих дисков (CKD Devices). Сейчас со штатной поддержкой такого, конечно, стало сложнее, но даже на базе обычного плоского файла сделать что-то можно — правда, границы записей придется искать самим в программе.
Но ещё лучше бы подошел другой артефакт тех же врмен: «индексно-последовательный набор данных» (который тогда обслуживался утилитой с примечательным именем, которое я помню до сих пор: IEBISAM): данные в нем располагались последовательно в порядке некоего ключа, и записи по этому кючу можно было искать. поэтому для задачи поиска по ключу в виде даты/времени записи он подошел бы лучше. И вот у у этого древнего артефакта есть прямой аналог — clustered index — в современных СУБД, по крайней мере — в некоторых (точно знаю, что есть в MS SQL, но вот за Postgress не скажу). То есть для приема логов в БД создается таблица с первичным кластерным индексом по дате/времени (лучше — с повышенным фактором его заполнения, чтобы не терять зря много места). Запись в нее фактически идет последовательно, без особых потерь на поддержку индекса (разделения блоков дерева там не будет, а поворот, чтобы дерево сбалансировать, может быть отложен и до момента, когда нагрузка снижается). А запрос для выборки по диапазону дат отлично оптимизируется по первичному индексу шатным планировщиком. Вот как-то примерно так можно было бы сделать.
SQL ведь по своему духу не похож на обычные императивные языки: там надо написать что нужно получить, но не надо(в идеале, жизнь сложнее) описывать как это получить. Поэтому расказывать истории — это IMHO не в духе SQL.
Аналогично с тестированием — тестировать лучше на специально подобранных данных. Для теста стоит завести тестовую БД со специальным наполнением и проверять запрос на ней. Правда, не знаю как там будет интеграцией с используемой IDE — можно ли «не отходя от кассы» сразу увидеть зелененькие огоньки прошедших тестов.
Плюс именно любимой работы при этом в том, что те же деньги получаешь за меньший объем делаемой работы, на нелюбимую ее часть — другая часть, любимая, делается для своего удовольствия ;-).
В частности — у нанимателей.
Ну что вам на это сказать? Подключитесь Outlook'ом к Exchange и посмотрите в логе IIS, через какой виртуальный каталог идет основной обмен. Или при запущенном Outlook вытащите его полное локальное меню (Ctrl+правая кнопка мыши на значке в области уведомлений), выберите там пункт про состояние подключения, и посмотрите, по какому протоколу подключен Outlook к ящику и адресной книге. Если Outlook и Exchange не слишком старые, то там почти наверняка будет MAPI/HTTP.
Да, MAPI over RPC остался, в основном, в прошлом, но MAPI/HTTP — это тоже вариант програмного интерфейса MAPI, только использующий другой транспорт: для кода Outlook работа с ним выглядит практически так же. И это важно, т.к. позволяет повторно использовать всю ту гору кода, которая уже написана.
А EWS в Outlook используется для вспомогательных целей: обмен информацией о занятости, управление оповещениями об отсутствии, получение подсказок от сервера при составлении письма…
Вот что-то мне, как человеку, профессионально занимающимуся Outlook и Exchange, это кажется сильно сомнительным. Outlook ведь для доступа к Exchange использует проткол MAPI — который проприетарный MS-овский, который весьма тяжелый, но который дает дает возножность доступа ко всем возможностям Exchange (к Exchange Online это тоже относится, не только к Exchange на земле). А ещё MAPI сильно привязан к Windows, потому что базируется на COM. Как это сможет жить на Mac — не представляю. Outlook для Mac, например, использовал не MAPI, а EWS, который доступа ко всем возможностям уже не дает. Ну, а тот же IMAP — да, он стандартный, но он дает доступ тоже только к вещам весьма стандартным.
То, что MS угробит конкурентное преимущество своей технологии ради сомнительных благ унификации — не верится.
Но я бы ещё после каждого разобранного понятия написал, как оно называется в больших и скучных учебниках — чтобы прокинуть мостик к этим учебникам, чтобы говорить с людьми, которые по ним учились, на одном языке, чтобы слова типа «третья нормальная форма» не ставили в тупик на собеседовании.
По-моему, вы несколько преувеличиваете сложность и дороговизну обеспечения высокой доступности. Поскольку я не специалист по Linux, а потому не могу подробно рассмотреть, как там обстоят дела с этим в нижнем ценовом сегменте, то расскажу про то, что может предложить людям экономным Windows Server во вполне стандартной комплекатции. Это, конечно, не экомом-класс (потому что сама цена на лицензию даже для Standard Edition весьма ощутима), но, по сравнению с ужасами кровавого энтерпрайза, все очень по-божески.
Начнем с отказоустойчивости приложения. Компонент отказоустойчивой (по-русски, точнее, но длиннее — способной обойти отказ, ибо по-английски это failover) кластеризации в эту самую стандартную редакцию встроен уже давно. И для задействования этого средства при написании приложения не нужно делать свой велосипед — достаточно реализовать небольшую DLL для взаимодействия со службой управления кластером. Более того, если приложение позволяет управление собой через COM, то вместо DLL можно ограничиться скриптом на JavaScript (или VBScript). А если приложение реализовано как служба Windows, и настолько просто, что его работоспособность/неработоспособность определяется исключительно по факту того, запущена ли служба, то для использования отказоустойчивой кластеризации можно вообще не писать никакой код: я, например, некогда написал статью про то, как можно сделать потешный (т.е. для развлечений, в бой совать его не надо) кластер DNS на базе стандартной службы из Windows Server. Ну, и для веб-приложений под IIS отказоустойчивая кластеризация тоже возможна (и есть руководство, как это настроить, где-то на сайте Microsoft), хотя для их развертывания в многосерверной конфигурации чаще применяют балансировку нагрузки (в том числе — и встроенную, которая есть в составе Windows Server).
Далее, высокую доступность сети для Windows Server можно обеспечить разными встроеными в него способами. Простейший и самый древний — объединить пару сетевых интерфейсов в виртуальный мост (он понимает STP) и подключить эти интерфейсы к разным коммутаторам, тоже понимающим STP. А кроме этого в Windows Server встроена агрегация сетевых интерфейсов (NIC Teaming) в нескольких вариантах: зависимая и независимая от коммутатора, статическая и динамическая — она тоже обеспечивает устойчивость к отказу сетевого адаптера/кабеля/коммутатора.
С отказоустойчивостью данных, да так чтобы обойтись без единой точки отказа доступа к ним (а не только обеспечить сохранность при отказе диска), если при этом ограничиться чисто Windows Server, немного сложнее. Но и тут вполне можно обойтись без дорогой SAN. Правда, стандартная редакция может предложить только построение на базе нескольких подключенных по iSCSI LUN на недорогих и не отказоустойчивых устройствах хранения (их требуется от 3-х штук) кластерного варианта Storage Spaces, на базе которого уже можно сделать отказоустойчивые виртуальные диски. Решение это несколько неуклюжее и костыльное (т.к. шатно Storage Spaces рассчитан на работу на базе локальных физических дисков), но, в принципе, работоспособное (хотя про необходимую полосу пропускания сети для него забывать нельзя). Но если появляется целесообразность использования более дорогой редакции Datacenter Edition (т.е. если служб становится больше некоего минимума), то в этой редакции есть гиперконвегентный вариант Storage Spaces — Storage Spaces Direct — который можно уже штатно использовать для построения хранилища на локальных дисках серверов без единой точки отказа.