LINUX.ORG.RU

Си. Почему бы не запретить запись в стек?

 


1

4

Решил немного разобраться как работают уязвимости. Как я понял, весомая их часть модифицирует стек.

#include <stdio.h>

register long unsigned rsp asm("rsp");

void print_arg(int arg) {
    ((int*)rsp)[3] = 0xBADC0DE;
    printf("arg = %x\n", arg);
}

int main(int argc, char **argv) {
    print_arg(0xF00D);
    return 0;
}

Этот код отрабатывает и не выводит ошибкок с

-fhardened -fcf-protection=full

На мой взгляд выглядит небезопасно.

Почему бы не вставлять проверки на ассемблере при записи в память, на включаемость в регион стека? Если нужно записать что то в аргумент на стеке (int), то проверку можно не вставлять. При записи по указателю, уже обязательно вставлять. Если адрес стека то ошибка. В memset проверять пересечение двух диапазонов.

Если на стек пишет fread(), то нужно вставить еще проверку на разрешающий диапазон буфера в который он пишет. Но тут компилятору нужно обязательно отслеживать откуда приходит поинтер, но если мы говорим про значения на стеке, то это не должно представлять сложности, значение всегда лежит в прошлых значениях стека, а значит вычислить размер буфера можно в момент компиляции, ну или записать в какую нибудь дополнительную переменную на стеке, если речь о сложном потоке управления и alloca.

void read_file(const char *name)
{
        char buff[999];
        FILE *f = fopen(name, "rb");
        read_block(f, buff);
}

void read_block(FILE *f, char *buff)
{
        // тут компилятор должен вывести что len(buff) == 999
        fread(buff, 1, 9999, f);
}

Что бы все идеально работало, нужно будет:

  • Пометить libc функции
  • Если функция работает со стеком как у меня в верхнем примере, но это правильное поведение, пометить и ее
  • Перекомпилировать основные библиотеки, что бы не ломать ABI можно ввести экспорт двух прототипов, с доп.значениями для проверки диапазонов и без, дублирование прототипов понадобится для малого числа функций
★★★★★

Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от Forum0888

API для управления памятью.

получается Objective C/C++ какой-нибудь, изобретать пулы объектов и ARC память

[ [[Object :newClass MyChild] alloc] initWithOID: 1 andName: @"MyObject"]

Профит в том, что API, использующее метаданные имеет в run-time данные об используемых полях объектов, …

:perform селекторы, интерфейсы и категории, ну или метаобъектный протокол изобретать и API по метаклассам

в общем, вот если бы взять не С++ а объектный Си

и CoreData – то бОльшая часть API там, наверное, уже реализована :))

опять же, метаданные и списки свойств key-value из CoreData и егойного интерфейса сериализации персистентных объектов…

anonymous
()
Ответ на: комментарий от anonymous

а вообще, нужно кодогенерировать всё это десктопно-графическое API вроде >какого-нибудь IUP,Nuklear,SDL или ещё какого Vulkan из более >высокоуровневого представления :))

Есть у меня предположение,что попытка сделать такой универсальный генератор на все случаи жизни приведет к тому,что в каждом конкретном случае он будет выдавать нечто не оптимальное или вообще плохое.

Например сейчас весьма часто встречаются программы,где для заполнения полей ввода в форме приходится регулярно отрывать руку от клавиатуры и хвататься за мышь чтобы в нужное поле ткнуть. Потому что реализованная навигация по полям ввода - только «последовательно по кругу» через какой-нибудь tab,и только в том порядке в котором их на форму добавляли,что совсем не всегда соответствует логике использования.

И вот этим и подобными скажем так особенностями страдают многие «стандартные диалоги» в монстроидальных библиотеках типа GTK и QT. Поменять и сделать как удобно,а не как получилось - возможно. Но для этого надо лезть достаточно глубоко внутрь. Что противоречит (или как минимум сильно усложняет) идее кодогенерации.

watchcat382
()
Ответ на: комментарий от watchcat382

студент просто сделал 2 кольца защиты (0,3) из доступных 4.

потом появились гипервизоры и появились -1, -2 и т.п. кольца защиты.

так сколько их должно быть реализовано чтобы это работало? например, если у нас будет 16 различных тайптегов у указателей – неужели понадобится 16 колец защиты? :)))

anonymous
()
Ответ на: комментарий от watchcat382

ЯП 1С много проще, чем скажем Python, ...
Основной аргумент в использования Python, ... пожалуй в том, что интегрировать 1С с каким-либо GUI не просто.

А GUI 1С в основном разработан для возможности использования объектов технологической платформы.
Поэтому-то и не разрабатывают для 1С много биндингов.

Всё же имеются ниши задач в которых 1С целесообразно использовать.

Например 1С легко интегрировать с любой СУБД.
При этом становится доступна функциональность, которой в 1С нет.
Для такого рода задач, использование 1С вполне приемлемо.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)
Ответ на: комментарий от watchcat382

Есть у меня предположение,что попытка сделать такой универсальный генератор на все случаи жизни приведет к тому,что в каждом конкретном случае он будет выдавать нечто не оптимальное или вообще плохое.

я потыкал DRAKON-Editor Степана Митькина на ActiveTcl.

он работает. и более-менее сносно кодогенерирует под все 20 языков из примеров.

но тоже есть замечания: например, switch кодогенерируется в корутины из замыканий, циклы в if и goto ну и т.п. по мелочи.

в общем, нарисованная ДРАКОН-схема работает и компилируется/исполняется.

но далеко не факт что кодогенерация всегда оптимальна.

шаблоны выходной кодогенерации там в общем настраиваются, но тут наверное скорее придётся лезть в исходники.

И вот этим и подобными скажем так особенностями страдают многие «стандартные диалоги» в монстроидальных библиотеках типа GTK и QT.

да, например в Nuklear свой ни с чем не совместимый велосипед.

anonymous
()
Ответ на: комментарий от anonymous

Разница в том, что подсистема управления памятью будет «заточена» на использование метаданных и run-time.

:perform селекторы, интерфейсы и категории, ну или метаобъектный протокол изобретать и API по метаклассам

Это всё compile-time.
Разрабатываемое API для run-time.
То бишь можно создавать и использовать объекты о которых компилятор ничего не знает.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от Forum0888

Сравнивая например, ИнфоПредприятие и 1Сv8 – модель событий у первого более гибкая, более расширяемая и удобная.

//да, я писал ActiveX компоненты для 1Cv77 и ОбработкуСобытия() –вот уж чудеса ограниченности :)))

опять же, сравнивая какой-нибудь условный смоллток или тот же объектный си с 1С.

взяли объект смоллток и сказали ему: породи пакет, метакласс, класс, объект. сконфигурируй, скомпилируй и замени все старые инстансы кода новым.

в общем, какой-нибудь сервер приложений.

так в 1С например подобное только через конфигуратор придётся делать. а он например, при сохранении примется базу реструктуризовывать.

потому что язык/модель событий/использования объектов недостаточно динамичная, гибкая и расширяемая.

anonymous
()
Ответ на: комментарий от anonymous

потому что язык/модель событий/использования объектов недостаточно динамичная, гибкая и расширяемая.

Для 1С 7.7 это неверное утверждение.
Например 1cpp позволяет создавать в контексте модулей переменные.
Более того, возможно в контекст любого модуля добавить динамически функции, которых в исходниках нет.
Это КОЛОНДАЙК для создания обобщённых алгоритмов!

Например у меня имеется алгоритм, обеспечивающих взятие из Firebird данных всех или отдельных таблиц.
А алгоритм то менее пятисот строк.

Так вот 1cpp позволяет легко создавать обобщённые алгоритмы в run-time!

Кстати эта функциональность позволила расширить функциональность
всех модулей для работы с диалоговыми формы без необходимости
без необходимости добавления в исходники никаких строк кода.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)
Ответ на: комментарий от Forum0888

1С++ – да, потому что его объекты реализованы во внешней компоненте.

я про отличия 4GL от гипотетического 5GL: «в режиме конфигуратора» можно задать некоторые действия, которые невозможно выполнить программно (или в режиме предприятия).

Ну, например, создать новый «класс» документа, настроить его метаданные – можно только «руками». или метапрограмму на AutoIt/AutoHotkey писать :)))

в общем, опять пример когда динамически можно получить более гибкое чем стандартное.

в 2Сgpl в этом смысле было более на смоллток похоже: они реализовали свой собственный интерпретатор и объектную модель, и обычные классы от встроенных мало чем отличались (например, их можно было переопределить или расширить).

Это КОЛОНДАЙК для создания обобщённых алгоритмов!

а что думаете про «Библиотеку Стандартных Форм» и попытку реализации паттернов проектирования на них?

чем гибче и динамичнее язык – тем проще получаются паттерны, и наоборот.

в С++ это ещё оправдано потому что отдельно типы как сущности времени компиляции, отдельно – рантайм-сущности.

но в гибких программных средах на мой взгляд – это должны быть одни и те же самые сущности, первоклассные объекты. только разный view на них.

anonymous
()
Ответ на: комментарий от anonymous

Ну, например, создать новый «класс» документа, настроить его метаданные – можно только «руками». или метапрограмму на AutoIt/AutoHotkey писать :)))

Вот не выносите «вердикты».
Обеспечил возможность в дубле md основной конфигурации изменять в run-time метаданные конфигурации (диалоговых форм и отчётов).
Это позволяет добавлять или изменять функциональность основной конфигурации динамически, а не «руками».

Проблемы у многих программистов от того, что они в основном «диванные теоретики» (это суждение не касается лично Вас).

Эта функциональность реализована на C++.
1С 7.7 она доступна с использованием биндингов на ActiveX.

Многие биндинги для 1С 7.7 можно использовать и для 1С 8.x, так как они не «прибиты гвоздями» к 1С.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 5)
Ответ на: комментарий от Forum0888

для 1Сv7.md вообще существовал gcomp кажется, который позволял компилировать/декомпилировать конфигурацию вытаскивая исходники в отдельные файлы и собирая назад через интерфейс IStorage (персистентных объектов в COM, например, так ещё были реализованы .doc, .mdx Access, .xls и почтовые базы аутлука)

то есть, если бинарные слабо документированные потоки декомпилировать – можно было и формы и классы сгенерировать, но это уже довольно низкий уровень.

Это позволяет добавлять или изменять функциональность основной конфигурации динамически, а не «руками».

а, понял. Вы наверное, 1C конфигуратором через СOM-автоматизацию управляли.

anonymous
()
Ответ на: комментарий от anonymous

вообще да, интересно почему исторически сложилось именно так а не по->другому.

Большая часть «исторически сложившегося» - следствие чисто аппаратных ограничений компьютеров тех лет когда это складывали. Ну не сделать было по-другому.

Меньшая часть - результат того что где-то в начале в какой-то тусовке так решили за бутылкой пива. И у решивших были личные связи чтобы пропихнуть это как «стандарт».

А еще бывает что где-то когда-то схалявили/схалтурили,недописали - а потом приходится годами тащить совместимость с этим. Вот поленился финский студент разобраться с сегментным мехнизмом 80386 и его правильно использовать - в результате получили ограничение в 4Гб на один процесс что в те времена казалось немыслимым количеством памяти,а сейчас некоторым не хватает. А могли бы иметь ограничение в 16381 сегмент по 4 Гб на процесс,то есть 64 терабайта.

watchcat382
()
Ответ на: комментарий от anonymous

а, понял. Вы наверное, 1C конфигуратором через СOM-автоматизацию управляли.

Да, для 1С 7.7 имеется API на C++, который по существу является core.
API можно и в Linux использовать.
В Windows интеграция с 1С реализована с использованием ActiveX.
Многие ActiveX толком то и не понимают и думают, что она пригодна лишь для диалоговых форм.
Всё как обычно - «Всё понял, только одного не могу понять. Куды же в трактор кобылу впрягать?».

Интересно то, что API пригодно как для работы с 1С, так и с любыми объектами, создаваемые динамически в run-time.
«Гвозди» не использую.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от anonymous

есть кстати, современая реализация Amiga на FPGA: Apollo. там реализовали в FPGA «процессор» MC68080, которого в природе физически >никогда не существовало

Жаль,всё что касается всяких ПЛИС - малодоступно частным лицам для экспериментов из-за цены самих ПЛИС(тех в который можно что-то подобное реализовать) и закрытости инструментария :(

watchcat382
()
Ответ на: комментарий от AntonI

Если это будет на железном уровне поддерживаться, то жить станет проще

Как я уже писал, для проверки границ можно задействовать сегментный механизм,который ЕСТЬ в интеловских процах. Его просто надо ИСПОЛЬЗОВАТЬ. Так,как это когда-то делали например дос-экстендеры и OS/2.

но код станет медленней;-)

Во-первых никто не заставляет использовать эти проверки вообще везде. Во-вторых немало случаев когда надежность важнее скорости. Особенно сейчас, когда скорости обычно с большим запасом.

watchcat382
()
Ответ на: комментарий от anonymous

а, понял. Вы наверное, 1C конфигуратором через СOM-автоматизацию управляли.

Не конфигуратором.
Разработаны метаданные, которые позволяют в run-time объект, в который можно загрузить метаданные любой конфигурации.
То бишь core не «прибито гвоздями к 1С».
Для интеграции с md используется API, которое позволяет изменять данные в md.

Публиковать интеграцию с 1С не буду.
Нет смысла.
Это API использовалось лишь для отладки API core, которое ничего об 1С не знает.
Можно его использовать для работы с 2D, 3D, звуком, ...

«Жизнь нужно прожить так, чтобы не было мучительно больно за профлудинные годы сидя на диване».

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 5)
Ответ на: комментарий от AntonI

У каждого фрагмента кода должен быть чётко зафиксирован автор

Что уже и делают все системы контроля версий,ориентированные на командную работу.

нужна база программистов всей Земли

Ну Гитхаб уже есть…

watchcat382
()
Ответ на: комментарий от anonymous

ld –gc-sections в линкере

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

в общем, осталось только переписать рантайм какого-нибудь языка >программирования чтобы эти секции полноценно использовать (изобретая >какую-нибудь контролируемую память из Aды, ога)

В линуксовой Аде контроль памяти программный. А например компилятор Meridian ADA мог работать с дос-экстендером(правда только своим) и использовать аппаратный контроль памяти. Мог и использовал. В MS DOS. Тридцать лет назад. Ну и само собой это можно было использовать в программах на Си не скажу что под любым экстендером. «гнусный» вроде не мог),а вот один из PharLap мог. Правда и стоил под пять сотен баксов даже «там»,потому и не был сильно распространен.

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

watchcat382
()
Ответ на: комментарий от anonymous

студент просто сделал 2 кольца защиты (0,3) из доступных 4.

Использование или неиспользование имеющегося в процессоре сегментного механизма не зависит от числа колец защиты. Можно и с двумя его задействовать как это делали дос-экстендеры. Нужен-то точно также «пользовательский» режим и «привилегированный». При нарушении защиты вызывается исключение и выполняется привилегированный код.

например, если у нас будет 16 различных тайптегов у указателей – неужели >понадобится 16 колец защиты?

Если то,на что указывает указатель, кладется в отдельный сегмент - то никаких тэгов у указателя не нужно для того чтобы сработало исключение при попытке что-то записать за границу этого сегмента. Да, для доступа по указателю нужно будет загружать сегментный регистр адресом этого сегмента. И вот эта операция была медленной на 80286 где сегментный механизм впервые появился. Потому что у 80286 небыло кэша в современном его виде. После этого фраза о якобы медленности операций с сегментами пошла гулять из одной статьи в другую. Как и о медленности некоторых других команд (например enter/leave), не слишком удачно реализованных именно на 80286.

Как работавший в начале 90х с защищенным режимом на низком уровне - могу сказать что тогда вообще не так уж часто встречались люди, умеющие это. О всяких тонкостях особо и спросить-то было некого. Приходилось экспериментировать и выяснять методом тыка как оно работает в тех ситуациях которые не слишком внятно описаны в документации. Подозреваю что ситуация у финского студента не так чтобы сильно отличалась от моей. Такой открытости технической информации и примеров кода как сейчас - тогда небыло.

watchcat382
()
Ответ на: комментарий от Forum0888

ЯП 1С много проще, чем скажем Python, …

Вот уж Python я бы никак не назвал простым языком. Он слишком «нестрогий»,в первую очередь в плане типизации, чтобы на нем было просто разрабатывать и поддерживать крупные проекты. Простота языка - это вовсе не возможность написать «Привет мир!» в одну строчку. А возможность легко управлять кодовой базой в сотни тысяч строк.

Если хотеть простоты - то смотреть надо в сторону чего-то паскалеподобного. Не просто так всякий учетный софт на Delphi и его подражателях не редкость и сейчас. Учетно-бухгалтерский софт - он алгоритмически не сложный,он просто объемный так как приходится учитывать множество мелочей,в том числе специфичных для конкретного места примерения. Кастомные конфигурации 1С тому пример. Поэтому какие-то особо навороченно-продвинутые языки типа лиспов с прологами и прочего высоконаучного - там не нужны. Всё равно не найти столько программистов которые смогли бы их эффективно использовать. А самые простые для освоения - это именно паскалеподобные языки.

Например 1С легко интегрировать с любой СУБД.

Можно подумать что к примеру Borland Pascal интегрировать с СУБД сложнее. Или чтобы быть поближе к теме Линукса - можно привести в пример современный FreePascal.

А GUI 1С в основном разработан для возможности использования объектов >технологической платформы.

GUI может быть библиотекой,и даже ориентированной на предметную область, подключаемой к ну не любому языку,но довольно широкому из множеству.

Для такого рода задач, использование 1С вполне приемлемо.

Я и не предлагаю выкинуть 1С прямо сейчас. Но вот как раз GUI там не слишком эффективный если смотреть со стороны например оператора ввода данных,владеющего слепым методом работы на клавиатуре. Да не как мы,программисты,а с той скоростью которая оператору ввода данных и положена. Попробуйте набить в 1С пачку документов не хватаясь поминутно за мышь,для чего руку с клавиатуры надо снять,а потом вернуть в положенную ей позицию. Другое дело,что хороший оператор ЭВМ встречается в жизни не чаще чем хороший программист.

P.S. Тут я правда оговорюсь,что последний раз видел 1С в работе достаточно давно. Но жалобы от операторов слышал и недавно.

watchcat382
()
Ответ на: комментарий от anonymous

И вот этим и подобными скажем так особенностями страдают многие >>«стандартные диалоги» в монстроидальных библиотеках типа GTK и QT. да, например в Nuklear свой ни с чем не совместимый велосипед

Дело даже не в самом велосипеде,а в возможности удобно поменять у него педали или седло если это потребовалось для оптимизации в данном конкретном применении. В данном случае - сделать в «стандартном диалоге» такую реакцию на клавиши чтобы человек,владеющий слепым набором на клавиатуре,мог работать с этим диалогом удобно,а значит быстро. Но сейчас такое ощущение что диалоги делались под пользователей,с трудом освоивших мышь,причем с одной кнопкой. И в самом крайнем случае набирающих буквы одним пальцем,мучительно разыскивая каждую.

watchcat382
()
Ответ на: комментарий от watchcat382

А вот ядра на ADA вполне себе уже есть. В том числе знаю два открытых: https://ironclad.nongnu.org https://muen.codelabs.ch

о, про первый есть дистрибутив со скриншотами: gh.com/streaksu/Glorie

ну чем не линукс :)))

anonymous
()
Ответ на: комментарий от anonymous

о, про первый есть дистрибутив со скриншотами:

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

watchcat382
()
Ответ на: комментарий от anonymous

интерпретируемая Ада в качестве шелла на замену Bash

Всё же не как замена собственно шелла (интерактивного режима командной строки),а как средство скриптописательства. И действительно - Ада хороша и в этом качестве. Да она вообще во всем хороша. Сорок лет назад её недостатком называлась сложность создания и тяжеловесность компилятора,а также высокий порог входа из-за размеров текста стандарта языка. Свободный компилятор уже давно есть и работает вполне быстро. А уж текст стандарта по нынешним временам каким-то особо большим точно не назвать.

Интересно - кто-нибудь из присутствующих сможет найти актуальные аргументы почему сейчас НЕ надо писать на Аде? Она ведь хорошо подходит для всего - от числодробильной математики и ядра системы до учета товаров на складе. Разве что где-нибудь там где занимаются программированием как высокой наукой - Ада не сможет конкурировать с Прологом,Лиспом или Хаскелем. Не настолько она головоломная как эти языки :)

Пожалуй единственное неудобство с которым столкнется начинающий адский писатель - это необходимость самому сделать «переходники» к тем библиотекам которые он собирается использовать. Готовых или нет или сделаны далеко не самым удобным образом(нередко вообще какой-нибудь довольно примитивной автогенерацией скриптом). То есть как в Си, написать #include и сразу использовать библиотеку не получится. Но например писателей на FreePascal не смущает же необходимость также делать переходники для сишных библиотек. Как и писателей на Питоне.

watchcat382
()
Ответ на: комментарий от watchcat382

Вот уж Python я бы никак не назвал простым языком.

Никогда не использовал, так как не было никакой необходимости.
Тот же C++ сложен не синтаксис, а множество ограничений.

Я и не предлагаю выкинуть 1С прямо сейчас. Но вот как раз GUI там не слишком эффективный

GUI 1С 7.7 - урезанный WinAPI (да ещё в придачу написан с использованием MFC) и дополненный своими controls.
Для 1С 7.7 можно правда «настрогать» свой GUI используя COM.
Проще всего, использовать WinAPI.
Разработал binding WinAPI для 1С.
Всё работает, но никогда не использовал, так как это - «баловство» .

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Аббревиатуры обычно не переводятся. ОКАТО с точки зрения языка ничем не отличается от NATO.

Однако, для НДС часто пишут поле VAT.

Для этого в исходниках пишутся комментарии. Желательно подробные.

Всё так. Но в результате чтение чужого куска кода напоминает чтение текста на иностранном языке со словарём, когда от каждого слова идёшь в словарь, потом возвращаешься к тексту. Вот прямо сейчас разбираю JSON c полями settlement, locality, ifnsULCode и oktmo. Ни русский ни английский…

А еще есть проблема перевода специфических областей знаний. Например, при автоматизации энергетики, как какой прибор и какой элемент энергетической сети называется на английском, даже в словаре не сразу найдёшь. Причём местами может быть словами, местами аббревиатурой и в одном месте airline, в другом — VL.

Ну не нравится им правильный русский - так выучили бы уже правильный английский и на нем общались. Что кстати уже и практикуется кое-где в интернациональных коллективах. Но им лень,поэтому используют жуткий жаргон как папуасы какие-то.

Для этого надо ТЗ на английском. Иначе будут фразы типа: We will save элемент планировочной структуры into field territory and элемент улично-дорожной сети into street. Почти такой же жаргон, но сдвинутый к английскому.

monk ★★★★★
()
Ответ на: комментарий от watchcat382

Можно подумать что к примеру Borland Pascal интегрировать с СУБД сложнее.

ORM, встроенный в язык и интегрированный c SQL, отсутствует.

Попробуйте набить в 1С пачку документов не хватаясь поминутно за мышь,для чего руку с клавиатуры надо снять,а потом вернуть в положенную ей позицию.

Сам 1С это позволяет. Более того, последовательность полей и их наличие можно даже в пользовательском режиме настроить. Программисты прикладных решений не всегда делают нормально (фактически, только место кассира по скорости оптимизируют).

monk ★★★★★
()
Ответ на: комментарий от Forum0888

Ностальжи

Ещё о GUI 1C 7.7 (на примере интеграции с ним).

Как-то разработал DecompileDialog.cpp.
Это декомпилятор любого диалогового окна Windows.

Как работает?

С помощью API для энумерации ресурсов Windows: EnumLangsProc.cpp,
EnumNamesProc.cpp, EnumResourcesModule.cpp, EnumTypesProc.cpp,
ExtractResource.cpp, GetInfoResource.cpp и LoadResourceMemory.cpp.

Находим адрес с которого находятся в run-time бинарные данные диалоговой формы и декомпилируем.
Результат - исходники диалогового окна для C++.
Конечно сделал интеграцию этого API с 1С.
Берём из md метаданные о любом диалоговом окне 1С, формируем бинарное представления диалогового окна для Windows, открываем его и ОПА 1С-овая родимое диалоговое окно.

Кстати API позволяет «воровать» диалоги с любой проги на Windows.

Просьба об этом виндусятникам не говорить.
Пусть будут уверены, что раз исходных кодов не публикуют, то никто и ничего с их проектов не сумеет взять.

PS: Всё возможно!
Нужно просто не рассуждать «сидя на диване», а ВКАЛЫВАТЬ!

С 1С-никами на эти темы не веду диалоги, так как они 99.999% «ЗНАЮТ 1C», а в этих вопросах не БУМ БУМ.

Ладно «расколюсь».
API позволяет в run-time иметь доступ к ресурсам любой Windows программы.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от watchcat382

И всё это монстрообразие 1С - чтобы товары на складе считать. Как-то из пушки по воробьям получается.

Всё это монстрообразие для огромных учётных систем. В Конфигурации 1С несколько миллионов строк кода.

Вот уж действительно - почему не взять любой «настоящий» язык программирования и не писать на нем?

Есть SAP. Получается любая задача в 2-3 раза дороже, чем на 1С. Есть Java, на ней задача ещё в 2-3 раза дороже.

Наделать библиотек для предметной области.

1С всё равно не получится. Какой библиотекой заменишь 1Сное &НаКлиенте, которое динамически компилируется в JavaScript и обеспечивает прозрачный обмен с сервером? Какой библиотекой заменишь панель объектов Конфигуратора?

monk ★★★★★
()
Ответ на: комментарий от watchcat382

Интересно - кто-нибудь из присутствующих сможет найти актуальные аргументы почему сейчас НЕ надо писать на Аде?

Отсутствие библиотек, фреймворков. Сейчас почти все связывается с вебом, нужно удобно работать с json, xml, уметь выполнять асинхронные запросы.

Нету бесплатных инструментов, хотя это не так уж и важно, если работу работать то и деньги найдутся. Какой нибудь C# так же безопасен, но и разработка на нем идет быстрее.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от MOPKOBKA

Отсутствие библиотек

Можно прицеплять сишные пока адские не написали. У Ады прямо в стандарте прописаны возможности для интеграции с кодом,написанным на других языках. Ну и самое главное - еще пару десятков лет назад готовых библиотек было еще намного меньше чем сейчас. Тем не менее там где были потребности - нужное написали. Особенно это касается относительно новых языков типа того же Питона.

Сейчас почти все связывается с вебом

Пример веб-сервера на Аде я видел еще лет двадцать назад. Сейчас может и что-то еще более продвинутое есть. Просто этой темой в последние годы не интересовался. Да и не связанного с вебом софта по-прежнему много. Если конечно под «связью с вебом» не иметь в виду запихивание веба внутрь программы типа как в Electron, с целью получения тормозов на имеющемся оборудовании и стимуляции пользователей к покупке нового.

Нету бесплатных инструментов, хотя это не так уж и важно, если работу >работать то и деньги найдутся.

Вот именно,что бесплатность инструментов критична только для частных лиц и совсем мелких стартапов каких-нибудь. В бюджете же крупной фирмы стоимость софта составляет весьма незначительную долю.

Какой нибудь C# так же безопасен

Не уверен в этом.

watchcat382
()
Ответ на: комментарий от watchcat382

Можно прицеплять сишные пока адские не написали.

На С сейчас обычный софт тоже не пишут.

У Ады прямо в стандарте прописаны возможности для интеграции с кодом,написанным на других языках.

Ну это почти везде есть, конкретно C ffi.

Пример веб-сервера на Аде я видел еще лет двадцать назад.

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

Да и не связанного с вебом софта по-прежнему много.

Я скорее про то что нужно отдать куда то данные по HTTP, или взять их.

Какой нибудь C# так же безопасен

Не уверен в этом.

Не смотрим на продвинутые инструменты Ada, их я думаю никто на простом софте применять не будет, сильно замедляет скорость разработки, но утечки памяти уже исключаем, use-after-free тоже уже не будет, за пределы буфера не вылезти, то есть на базовом уровне закрывает столько же проблем сколько и Ada. При этом имеет много вкусностей от высокоуровневых языков.

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

Не смотрим на продвинутые инструменты Ada, их я думаю никто на простом >софте применять не будет, сильно замедляет скорость разработки

Замедляет оно только и исключительно в самом начале,пока не разобрался как на Аде писать чтобы эти инструменты помогали,а не мешали. Собственно, это справедливо для любого языка кроме самых простейших.

В Питоне вон вообще значащие пробелы как на перфокартах ЕС ЭВМ - и ничего,питонописателям это не мешает,очень бодро код строчат.

но утечки памяти уже исключаем, use-after-free тоже уже не будет, за >пределы буфера не вылезти, то есть на базовом уровне закрывает столько же >проблем сколько и Ada.

С этим согласен.

При этом имеет много вкусностей от высокоуровневых языков.

А Ада это что - не высокоуровневый что ли?

watchcat382
()
Ответ на: комментарий от watchcat382

В Питоне вон вообще значащие пробелы как на перфокартах ЕС ЭВМ - и ничего,питонописателям это не мешает,очень бодро код строчат.

Я возможно тебя удивлю, но любой код форматируют, поэтому в питоне пробелы не являются чем то лишним, как отступы в начале строки в старом фортране или коболе, ну и IDE их правильно расставляет уже.

А Ада это что - не высокоуровневый что ли?

Я про всякое метапрограммирование и создание классов на лету. LINQ еще есть.

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

Хм, а у меня вот выводит «1,1».

А Ваше «0,1» - это издержки работы оптимизатора. Он по возможности тянет a и b в регистрах - в память пишет, а в регистры не перечитывает. В современном C для «1,1» нужно использовать volatile - f(volatile int a, volatile short b).

anonymous
()
Ответ на: комментарий от anonymous

Хм, а у меня вот выводит «1,1».

Может выводить что угодно, в зависимости от компилятора, версии компилятора, флагов компилятора.

это издержки работы оптимизатора

Нет, неоптимизирующий компилятор имеет право такое выдавать.

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от watchcat382

Пожалуй единственное неудобство с которым столкнется начинающий адский писатель - это необходимость самому сделать «переходники» к тем библиотекам которые он собирается использовать. Готовых или нет или сделаны далеко не самым удобным образом(нередко вообще какой-нибудь довольно примитивной автогенерацией скриптом). То есть как в Си, написать #include и сразу использовать библиотеку не получится. Но например писателей на FreePascal не смущает же необходимость также делать переходники для сишных библиотек. Как и писателей на Питоне.

есть ключик -fdump-ada-spec :

$ gcc -c -fdump-ada-spec -C /usr/include/time.h 
$ gcc -c *.ads

(имеется в виду gcc из GNAT)

для C++ немного сложнее из-за различий в С++ ABI и шаблонов, но тоже не очень сложно.

anonymous
()
Ответ на: комментарий от watchcat382

Но например писателей на FreePascal не смущает же необходимость также делать переходники для сишных библиотек.

вообще в gcc-ada, gpc (gnu pascal) есть здравая идея:

  • привязки должен генерировать сам компилятор
  • несколько фронтэндов, общий кодогенератор

например, gpc имеет похожие на pragma(C,import) прагмы.

по паскалям вот Владимир давал ссылку на ucsd-pascal и p-code:

здесь у первой книги [p-Source A guide to the Apple Pascal System, Randall Hyde](http://pascal.hansotten.com/uploads/ucsd/apple/ii/Hyde_P-Source-A Guide to the APPLE Pascal System_1983.pdf) интересный автор.

Это – тот же Randall Hyde который автор книги The Art Of Assembly и языка HLA – высокоуровневого ассемблера с синтаксисом, похожим на паскаль, но с семантикой С++ и довольно продвинутой макросистемой (например, аналог STL, исключения, оконная система под Win32 и ООП сделаны на этом CTFE, compile-time function execution).

при этом это – всё ещё ассемблер, ибо элементарные выражения нужно писать в терминал машинных типов и регистров (хотя можно и написать макросов поверх)

Владимир в другом треде писал ссылку про интерпретатор p-code, вот другой любопытный досовский

ucsd p-system

P6 Pascal вообще стоило бы переписать либо на Аде либо на HLA либо на обоих сразу :))

ещё на www.moorecad.com/standardpascal есть занятные реализации ISO Pascal (P5, P6).

ещё с того сайта занятное: про Эдсгера Дейкстру, например цитатник

Разве что где-нибудь там где занимаются программированием как высокой наукой - Ада не сможет конкурировать с Прологом,Лиспом или Хаскелем. Не настолько она головоломная как эти языки :)

в архиве PAL по ссылке рядом с SparForte, TIA, Book of Ada Linux programming есть исходники какой-то примитивной продукционной системы на Аде :)

вспомнилась цитата какого-то учёного из 80-х, что через 20 лет не понадобится никаких языков слабее Ады или Common Lisp :))

«не будет ни кино, ни театра, ни книг – одно сплошное телевидение» :))

20 лет прошло, а С++ и Питон и сейчас активно рекламируют из каждого утюга :))

“The prisoner falls in love with his chains.”

“A programming language is a tool that has a profound influence on our thinking habits.”

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, “Dijkstra would not have liked this”, well that would be enough immortality for me.”

anonymous
()
Ответ на: комментарий от anonymous

“Don’t try to teach a pig to sing. It wastes your time and annoys the pig.”

“Your audience is like a pig; it swallows everything, even the good stuff.”

FORTRAN —”the infantile disorder”—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use. 

PL/I —”the fatal disease”— belongs more to the problem set than to the solution set. 

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. 

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. 

APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English. 

About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. 

Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer.
anonymous
()
Ответ на: комментарий от anonymous

есть ключик -fdump-ada-spec

Главное не ограничиваться использованием этого ключика и сделать нормальные переходники. Такие,чтобы их было удобно использовать из Ады. Автоматически нагенерированное - использовать очень уж неудобно. Например вместо нормальной передачи переменной,с адской проверкой типов, будет передача ее ’address и постоянные unchecked conversion. Так вот это - должно быть спрятано внутрь пакета-переходника. А наружу для использования должны торчать уже нормальные адские функции.

Технические неудобства при вызове сишных функций возникают практически только в тех случаях когда сишная функция принимает «неопределенное» число параметров. Но и это можно обойти тем или иным способом зависимо от конкретного случая.

watchcat382
()
Ответ на: комментарий от anonymous

P6 Pascal имеется в виду этот: gh.com/samiam95124/Pascal-P6

собирается оно с помощью GPC, GNU Pascal. с официального сайта что-то уже не дают скачать, хотя пару месяцев назад качались и бинарники, и исходники.

но гитхаб всё помнит: gh.com/hebisch/gpc

надо им попробовать собрать TeX-GPC : gh.com/classic-tools/TeX-GPC ctan-ann/pkg/tex-gpc

и затем вот эти классические P2..P5, P6 и Pascaline, P-code и Pascal-M c cайта pascal.hansotten.com

tex-fpc на CTAN тоже есть

anonymous
()
Ответ на: комментарий от watchcat382

да, мне в книжке про Linux Ada programming тоже не понравилось в конце в исходниках про демона на Аде :)) – POSIX обёртки и многозадачность через форк и сигналы, хотя есть же нормальные кроссплатформенные task :)

anonymous
()
Ответ на: комментарий от anonymous

вспомнилась цитата какого-то учёного из 80-х, что через 20 лет не >понадобится никаких языков слабее Ады или Common Lisp :))

Вот и я о том же - что Ада не может хорошо заменить разве что особо высоконаучные языки типа Лиспа.

20 лет прошло, а С++ и Питон и сейчас активно рекламируют из каждого утюга

Из каждого утюга рекламируется еще и всякая малосъедобная еда - но это не значит же что ее надо обязательно есть. И вообще рекламируется очень много чего. И чем громче реклама тем обычно хуже товар.

watchcat382
()
Ответ на: комментарий от anonymous

POSIX обёртки и многозадачность через форк и сигналы, хотя есть же >нормальные кроссплатформенные task :)

Мы с Вами правильно поняли друг друга. Именно нечто подобное я и имел в виду когда говорил что переходники надо не просто генерировать, а вдумчиво писать так чтобы их было удобно использовать именно из Ады в сочетании с ее стандартными средствами. Тогда кстати даже и в рамках классического стандарта Ада83 неплохо получается писать - что я в 90е годы и делал. В новом стандарте уже ничего существенного писать не приходилось - он появился уже после того как я ушел из профессии и переквалифицировался в программисты-любители :) Хотя мне понравилось то что, делая новый стандарт его авторы смогли не испортить хороший язык. Обычно-то наоборот бывает.

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)