Культура «пет-проектов» должна умереть.
Я за утилитарный подход: нужна тебе какая-то программа, чтобы делать то, что другие не могут или могут, но не так, как тебе нужно – открываешь среду разработки (или текстовый редактор), пишешь код, а потом его используешь. Со временем у тебя таких программ набирается тонна, и ты все их используешь с той или иной периодичностью, выпиливая баги и модифицируя под новые условия. Можешь даже делиться с народом удачными или потенциально общественно полезными программами.
Ну, типа как, не нравится тебе как дверца в шкафу весит – берёшь, перевешиваешь её и пользуешься. Можешь даже кому-то ещё перевесить, если кто нуждается.
В культуре же «пет-проектов» оные проекты предстают в виде эдакого особого объекта, который необходимо выдавить из себя и упорно заниматься им хотя бы раз в день.
Одни вопрошают, каким бы «пет-проектом» заняться, ибо ничего придумать не могут, а надо. Другие рекомендуют придумать себе «пет-проект» и регулярно заниматься им, чтобы потенциальный хээр видел, что ты – серьёзный кандидат, «пет-проектом» занимаешься, а не объебос какой-то. Третьи жалуются, что десяток «пет-проектов» не оставляют времени работу работать и личной жизнью заниматься.
Ну, вы же не ломаете с утра до ночи голову над вопросом, какой бы гвоздь куда-нибудь вбить, а потом ежедневно гнуть его по-всякому, чтобы однажды кому-то его показать и доказать, что ты серьёзный чел, с гнутым гвоздём в стенке, а не объебос какой-то.

Написала тестовую программу, которая парсит заголовки Win16 и Win32 программ, показывая интересные данные вроде версии подсистемы, типа подсистемы, контрольной суммы, имени и описания модуля, ну и так далее. А теперь не знаю, что делать со всем этим кодом.

Помнится, в Windows 9x для удалённого запуска компонентов требовалась специальна программа на сервере. Одна постоянно висела в панели задач, но работала надёжнее, в вторая как-то фоном, но с ней вечно какие-то проблемы были. И ещё была утилита, которая позволяла прямо в реестре указать, что какой-то компонент должен выполняться на удалённой машине. Только это было реально двадцать лет назад, и я даже названий не помню этих программ, только иконку первой и её окошко. Ну и то, что вторая называлась dcomcnfg.exe, и нынче она вызывает MMC с оснасткой управления DCOM'ом.

Неожиданно удалось запустить ActiveX компонент удалённо. Тоесть, на одной машине зарегистрирован сервер ActiveX EXE, написанный на VB6, а на другой его объект пытается создать клиент, написанный тоже на VB6. При чём, раньше у меня всё время были какие-то проблемы, а в этот раз просто накидала тестовый проект, зарегистрировала, а на другой машине просто сделала «CreateObject(ProgID, ComputerName)», и всё. Клиент рулит объектом у себя, а код исполняется на другой машине. Единственное что, пришлось файрволл поковырять.

If you start off on Python before learning more beginner-friendly languages like JavaScript or Ruby [...]

https://medium.com/codex/le...-choice-5c8af5cb45a8
Кстати.

All things considered, why not start off on a watered-down version of Python rather than dive right in?

Заметила странность с DLL, собранными FreeBasic, в Windows 95. Допустим, у нас есть библиотека на FB, есть программа на VB6, которая её использует. Запускаем программу, она грузит библиотеку, всё хорошо. Теперь делаем ActiveX DLL на VB6, которая использует библиотеку, регистрируем через RegSvr32 в Windows 95. RegSvr32 грузит библиотеку, та грузит свои зависимости, в том числе FB библиотеку, а потом RegSvr32 получает от LoadLibraryEx() ошибку 0x45a. Даже если просто сказать RegSvr32 регистрировать FB библиотеку, то будет та же ошибка. Не понимаю, что происходит. В Windows 98 работает без проблем.

Короче, есть библиотека на FreeBasic, которую я использую в программах на VB6. Все объявления функций – в TLB файле. Добавила пару функций для кое-каких манипуляций с датой. Функция принимает один параметр типа Date (Double), производит манипуляции и возвращает дату в другой параметр того же типа. Возвращаемое значение Boolean (VARIANT_BOOL) сообщает, получилось произвести манипуляции или нет. Внутрях в том числе используются функции вроде VariantTimeToSystemTime() для конвертации в SYSTEMTIME. Вооот. Начались вылеты тестовой программы. Сначала выполнялась функция, а в конце случалось исключение. При чём WinDbg говорил, что беда случается в функциях категории SysStringLen(), которые работают с BSTR. Учитывая, что проблемный код не оперирует никакими BSTR, зато в тестовой программе функции вызывались прямо при конструировании строки с «отчётом» о проверке, выглядело всё так, словно где-то в библиотеке портится память, а потом всё ломается в программе. Ибо в программе не использовалось ничего особенного кроме для манипуляций со строками. Я долго вдумчиво смотрела в код, думала, какие-то проблемы с указателями, что-то не так передаётся во второй параметр, который указатель, либо не так вызываются функции конвертации даты из Date в SYSTEMTIME. Но там всё выглядело нормально. Кроме того, меня как-то настораживало сообщение: «Инструкция по адресу "0x77159d90" обратилась к памяти по адресу "0x0000fffb"». И второй адрес-то был всегда один и тот же. Откуда же он такой интересный? В общем, я посмотрела ещё раз исходник TLB и обнаружила, что по причине, связанной с ночным копипастингом, у меня возвращаемое значение (на самом деле – последний параметр функции) объявлено не как VARIANT_BOOL, а как BSTR. Я сваяла объявления в самом начале и больше даже не заглядывала туда. И вот что происходило. VARIANT_BOOL – это двухбайтовое целое со знаком (потому что совместимость с OLE в Win16), которое принимает значения 0 или -1 (кстати, частый вопрос, почему именно -1, а не 1), а BSTR – это четырёхбайтовый указатель на массив двухбайтных символов. Функция, возвращая True, записывала -1 в параметр, а код на VB6 получал указатель 0x0000FFFF. «FFFF» – потому что -1, а нули, полагаю, из-за выравнивания. Так как рантайм думал, что получает BSTR, а VB код возвращаемое значение прямо к строке присобачивал, полагаясь на автоматическую конвертацию, то рантайм вызывал BSTR функцию. Функция, чтобы получить реальный адрес строки, вычитала четыре байта (перед массивом у BSTR идёт длина строки), получала 0x0000FFFB, обращалась к этому адресу и благополучно вылетала. Вот такая история невнимательности.

«COM, DCOM, OLE. Всё это разные лица одного ануса. Тоесть Януса».

Не прошло и трёх лет, а у меня, наконец, дошли руки до ActiveX компонентов, вызываемых без регистрации. Оказалось, что сложного там ничего нет, нужно будет автоматизировать генерацию манифестов. Единственное что, в NT4 и Win9x не работает (хотя, в Windows 98 зачатки какие-то были).

UNIX время – это число с плавающей точкой, в UTC (нулевой часовой пояс), без дополнительных секунд. Всё верно? Запуталась уже =_=

Ранее я писала, как Win16 выдавала мне страшное сообщение об ошибке при попытке вызвать функцию из не найденной DLL в VB3. Я подумала и нашла источник проблемы. Есть в Windows такая функция SetErrorMode(), которая устанавливает глобально для задачи (процесса в Win32), как будут обрабатываться некоторые ошибки. Например, можно сказать, чтобы при возникновении необработанного исключения программа просто схлопывалась и не выдавала никаких «Память не может быть read». Есть там флаг SEM_NOOPENFILEERRORBOX, который именно на это и отвечает. Если установить его для задачи, то выдача страшных сообщений прекратится, пользователь не будет знать, что программа чего-то не нашла, а программа сама будет действовать альтернативно. Собственно, после установки этого флага, сообщения прекратились. А в Win32 он вроде как установлен по умолчанию (хотя, документация говорит обратное), но, как мне показалось, даже если его сбросить, никаких сообщений не появится.

There is a horrible non-obvious quirk of the Adjust­Token­Privileges function that is tripping us up: The function returns success even though it may have failed to do what you asked.
The function “succeeded” in the sense that it successfully attempted to adjust the privileges you requested, and it successfully reported the result of the adjustment attempt. But that doesn’t mean that the attempt actually accomplished what you asked it to do.

https://devblogs.microsoft....0211126-00/?p=105973

В Windows 3.xx, если VB3 программа пытается вызвать функцию из отсутствующей DLL, появляется то самое системно-модальное окно сообщения, поясняющее, что данной библиотеки не найдено. После этого (если не установить обработчик ошибок) уже VB рантайм вываливает ошибку «File not found» и схлопывается. В принципе, это происходит и при запуске такой программы в NT и 9x. А вот в VB6 такой фигни нет.

У MessageBox() есть ещё один прикольный флаг – MB_SYSTEMMODAL. В Win32 он ничего заметного не делает (документация говорит, что окно сообщения появляется поверх всех окон, что эквивалентно MB_TOPMOST), зато в Win16 показывает окно сообщения, которое блокирует всю систему пока не нажмёшь на кнопку. При этом, если не указать флаг иконки или указать MB_ICONSTOP, то показывается простейшее окно фиксированного размера, без заголовка (текст заголовка пишется отдельной строкой), с текстом шрифтом System и кнопкой. Такое окно рассчитано на ситуации, когда системные ресурсы закончились, система не может даже окно нормально нарисовать, но сообщение показать всё равно нужно, и делается это минимальными средствами. Если же указать другую иконку, то показывается обычное окно сообщения, только с одинарным бордюрчиком и без возможности окно это перетаскивать. Система при этом всё равно блокируется. Ещё одна интересная особенность заключается в том, что в Win9x приложения Win16 могут показывать такое окно с полной блокировкой системы, а Win32 приложения – нет. В NT даже Win16 приложения не могут заблокировать систему.

В Windows есть функция MessageBox() сотоварищи, которая выводит окно с сообщением, иконкой и набором кнопок для реакции пользователя. Для выбора иконки есть следующие флаги:
• MB_ICONHAND – выводит красную фигню с крестиком, типа, сообщение об ошибке.
• MB_ICONQUESTION – выводит фигню с вопросительным знаком.
• MB_ICONEXCLAMATION – выводит фигню с восклицательным знаком, типа, предупреждение.
• MB_ICONASTERISK – выводит фигню с буквой «i», информация.
В глаза бросается некое несоответствие названия констант тому, что они показывают. Более того, у MB_ICONHAND есть вносящий ясность псевдоним – MB_ICONSTOP. Что такое? Почему так? Дело в том, что названия констант говорят о том, что показывало окно сообщения в самой первой версии Windows. Тогда вместо креста при ошибке показывалась поднятая рука, а вместо буквы «i» – «*». В Windows 3.x руку посчитали неинтересной и стали показывать знак «Движение без остановки запрещено», и у константы появился «псевдоним», отразивший новые реалии. Та же фигня и со звёздочкой: появилась буква «i», и константа начала называться MB_ICONINFORMATION. В Windows 9x и NT4 иконки снова обновили, вместо знака появился крест, и авторы решили перейти от формы к содержанию, добавив псевдонимы MB_ICONERROR и MB_ICONWARNING. Получилась занятная капсула времени.

Забавная штука, которая встречается в QuickBasic, VBDOS, а так же в VB до третьей версии включительно. Короче, объявляю MessageBox(), потом вызываю её. «Duplicate procedure name». Начинаю разбираться, вдруг она где-то ещё объявлена. Нет, всё в порядке. Перезапускаю IDE – бывало там что что-то не работало без перезапуска – но тоже нет. Замечаю, что это функция, а вызываю я её как процедуру (функцию без возвращаемого значения), ну и добавляю скобочки и Call, как то и дело для наглядности делаю в VB6 и VBScript. Но снова ничего не работает. Догадываюсь, добавляю получение возвращаемого значения, и всё начинает работать. И вот по забывчивости я несколько раз ловила такой прикол в разных, хоть и подобных языках. И каждый раз много думала =_=

Я чего с сегментами памяти прерываниями DOS заморачивалась? А вот для чего.

QuickBasic от QBasic помимо наличия компилятора отличается ещё и возможностью запилить проект из нескольких модулей. Как-то раньше не требовалось пилить программы из нескольких модулей на QB ^^'

В порыве ностальгии научилась на QuickBasic получать PSP программы, а оттуда – блок с переменными окружения. Говорят, что за ним находится имя текущего екзешника, но пока это работает только в DOSBox.

В программизме самое сложное – рассматривая очень старый, местами неказистый, код, не думать, что человек, который его писал – не очень умный человек, а вот сейчас-то у тебя опыта больше и такую фигню ты больше писать не будешь. Короче, есть такая функция, GetLongPathName(). Думает она то же, что и GetShortPathName(), но в обратную сторону. В Windows 9x и NT4 её не было, и народ там страдал. Функция полезна, например, тем, что позволяет сделать регистр символов в произвольном имени файла как оно на самом деле на диске. Но в Windows 9x её нет, как и в NT4, а описание GetShortPathName() рекомендует использовать FindFirstFile() для нужного нам эффекта. Поскольку эта функция возвращает не прямо полное имя файла, а только имя без пути, нужно пробежаться по всему имени файла и для каждого компонента применить эту функцию. Муторно, но реализуемо, что я и сделала в далёком 2013 году на Цэ. Но вот мне потребовалось то же самое на FreeBasic, и, глядя на тот код, стало грустно. Решила написать заново. Получилось довольно ловко, хитро и гораздо компактнее. И всё заработало! Но потом полезли нюансы, каждый из которых надо было учесть, что влекло увеличение кода и потерю ловкости. Но самое печальное – не было всего этого в коде на Цэ, и из него не лезли все эти нюансы! Короче, пострадала, попечалилась и портировала код на FB, заодно отловив один баг. И вроде не такой уж и неуклюжий код то был, тоже ловкий, просто большая часть непонятного мусора – управление строками. В итоге у меня снова всё работает под Windows 9x и, что немаловажно, на NT4.