Пока мы ломали копья вокруг FreeBasic и FASM, случилась X Y проблема.

Как оно было? Моя библиотека (которую используют почти все мои программы, написанные на VB6) содержала пару функций для записи сообщений в журнал Windows, так же она содержала ресурс с шаблоном сообщения, который использует системный просмотрщик событий, ну и прописывалась источником этих самых шаблонов (источник событий). В Windows NT4/2000/XP всё работало офигенно: события пишутся, выводятся, замечательно. В x64 Windows 7 выяснилось, что просмотрщик не видит шаблона. Запись в реестре есть, файл есть, шаблонов нет.

«Разные разрядности!» – решила я и даже как-то не подумала посмотреть, что там с другими истониками. Тоесть x64 система почему-то не видит ресурсов в x86 DLL.

Однажды у меня дошли руки до сооружения отдельной DLL с ресурсом для x86 систем и отдельной – для x64 систем. Тоесть при установке программы копируем нужный файлик, и система его радостно использует. Исходную библиотеку я пишу на FreeBasic (предыдущая версия была вообще на VC++ 6), ну и эти ресурсные я решила запилить на FreeBasic.

Тут же появилось две проблемы. Во-первых тяжёлый фрибишный рантайм, впиливающийся в код библиотеки (у VB рантайм, например, хранится в легендарном MSVBVM60.DLL). Оказалось, что чтобы его искоренить, нужно всю компиляцию делать руками и городить костыли. А во-вторых, компиляторы, поставляемые с FreeBasic работают по принципу «Делаю бинарник только своей разрядности». Тоесть x86 бинарник делается x86 версией компилятора, x64 – x64 версией компилятора, а под линупс (if any) вообще под линупсом надо собирать. А я на XP :}

И тут вспомнился, собственно, FASM, который по своей природе не содержит рантаймов (ассемблер же) и собирает где угодно какой угодно бинарник (ассемблер же). Им я и сделала нормальные ресурные DLL.

А потом я задумалась, как их устанавливать. В реестре, в записи источника событий не указывается отдельно разрядность. Но что если просмотрщик будет не той же разрядности, что и система? Начала экспериментировать на x64 системе.

И тут я сделала два важных открытия. Во-первых, источник событий для моих программ прописывался без пути, просто именем файла. А во-вторых, он лежал в SysWOW64, поскольку x86. Иными словами, просмотрщик не то что не мог загрузить ресурс, он тупо не находил файл там, где ожидал его увидеть – в System32. Когда я прописала абсолютный путь, все события сразу же начали показываться нормально и с x86 DLL. А когда я посмотрела, как событие VB6 рантайма прописано по соседству, то нашла там запись в духе «C:\Windows\SysWOW64\msvbvm60.dll».

Всё это время я решала не ту задачу. Настоящим решением должно стать прописывание полного пути к DLL для новой библиотеки (при установке программы, которая её использует) и создание симлинка в System32 для старой (там код я поправить уже не могу).

This function dates back to Windows 3.1, back when a powerful computer had 4MB of memory, and your typical computer had much less. Software development kits cost thousands of dollars, and the expectation was that if you bought one, it was because you were a professional developer who understood how the system worked down to a very low level. Programming was hard because nobody expected it to be easy.

https://devblogs.microsoft....0210928-00/?p=105737

Одна из приятных особенностей использования FASM заключается в том, что чтобы сделать x64 бинарник, не нужно запускать x64 компилятор на x64 системе. Достаточно указать в исходнике, что это будет за бинарник, и нужный код будет сделан даже на x86 системе.

Пыталась сделать на FreeBasic resource only DLL (источник сообщений журнала событий Windows). Собственное, мне нужно было две версии: x86 и x64 для разных версий Windows. Делалось это весьма просто, но несмотря на отсутствие какого-либо кода в единственном BAS файле, FB писал в екзешник рантайм и всё такое. Пыталась побороть это ручной компиляцией без рантайма. А потом вдруг вспомнила, что у меня же есть FASM, у которого по понятным причинам нет никакого рантайма. Так я снова вернулась к ассемблеру =_=

Ранее я исправила один баг в своей программе, который проявлялся в Windows 98. Сегодня узнала, что в NT4 баг никуда не исчез =_=

Решила кое-что посмотреть в одной библиотеке. Нашла баг, проявляющийся в Windows 9x. Пытаюсь исправить.

Иногда я почитываю каналы и паблики с шутками про программистов. Обычно, половина шуток там про сложность языков вроде Цэ, «Не объявил переменную – код сломался», сравнение размеров кода на Цэ и путоне, где половина строк  – объявление переменных... А другая половина шуток, как нетрудно догадаться, про опечатку в имени переменной.

Прикольно. Берём HTML Object Library, делаем некий HTMLDocument, в котором будет тэг A со ссылкой в HREF и идентичным содержимым. Теперь заменяем HREF на другую ссылку (любую, главное чтобы в начале протокол был такой же). Вместе с HREF заменяется содержимое тэга. Как? Зачем? Почему?

Оказалось, что неразрывный пробел считается валидным символом в именах в VB6. Тоесть можно делать переменные, функции, константы с именами вида «Do It Already()».

Мало мне было лесенок, так ещё и это изобрела.
https://gist.github.com/Lin...d21bc19d6b1046382662

Зачем-то написала конвертер файлов рассказов (используя ранее написанный парсер) в отоформатированные текстовые с фиксированной шириной строки. Как в старые времена, когда мало кто умел переносить текст. Алгоритм получился дуболомным, но работающим. Собственно, именно вот это форматирование текста в блок фиксированной ширины уже давно хотела написать, лет двадцать, наверное, но руки никак не доходили OO Ради прикола сделала вариант сохранения в OEM кодировке. Оказалось, что в cp866 нет кавычек-ёлочек, так что пришлось делать замену на обычные кавычки.

уж лучше заставить юзеров всё своё перетегать. ты только дай этим юзерам волю - они ж заебут!

#zlvlo/#8
Вся суть современной разработки.

Больше всего терпеть не могу делать в программах объект-документ. Ну, чтобы открывался файл, отслеживались изменения, запросы там на сохранение... И всё это в отдельном объекте, а не в куче с кодом, собственно, обработки данных.

Пишешь утилиту, долго тестируешь, подсовываешь самые заковыристые данные, учитываешь даже пролёт нейтрино мимо процессора. Всё работает, ничего не падает, программа пуленепробиваема. Начинаешь использовать на реальных данных. Делаешь первый запуск...

У меня все рассказы в текстовых файлах, оформленных по стандарту. Есть утилита, которая красиво перегоняет текстовые файлы в HTML для сайта. А теперь я, наконец, запилила из кода утилиты библиотеку, которая парсит текстовые файлы в кучу объектов. Типа, объект рассказа, у него свойства «Серия», «Название», коллекция строк, ну и так далее. Короче, повозилась, придумывая структуру всего этого, но результат уже налицо: все выходные курила формат FB2, а сейчас уже у меня есть работоспособный конвертер, который ещё надо допилить по мелочам, но уже делающий готовые электронные книжки. Так же библиотека поможет мне генерировать тексты для отправки на всякие пиксивы и аотри. Теперь – самое сложное: переделать утилиту, чтобы она тоже использовала библиотеку.

Ультимативная замена жуквери.
https://gist.github.com/Lin...03aa4a01370d5f04d895

По мере возможности заменяю в своих скриптах код вида

if (document.querySelectorAll)

на код вида

if ("querySelectorAll" in document)

Всё правильно делаю?

? StrComp("0anime", "[anime", vbBinaryCompare)
-1
? StrComp("0anime", "[anime", vbTextCompare)
1

Когда забываешь, что vbTextCompare – это не только сравнение без учёта регистра.

Вчера я узнала, что парсер VB IDE знает о ключевом слове CDecl в Declare и не ругается на него. Правда, вызов функции, объявленной так, всё равно приводит к ошибке «Bad DLL calling convention», при чём сразу же, без попытки что-либо сделать вроде загрузки DLL. Думаю, что это что-то оставшееся в наследство от QuickBasic.

Чувак городит какие-то вавилоны из классов лишь бы не использовать switch. А мы потом удивляемся, чего программы тормозят.
https://betterprogramming.p...instead-aef014c9b31d