На каком языке и с применением каких технологий, IDE лучше писать программы для Windows, которые бы занимали минимум оперативной памяти?

Question

[dollar]

Такая программа должна иметь возможность работать с файлами, отслеживать работу других процессов (обращение к диску, к сети), иметь скромный GUI, доступ к сети. В общем, ничего необычного. То есть это не какая-нибудь игра, а простая системная утилита для какой-то специфической функции или отслеживания чего-то, которая незаметно сидит в трее, или вообще работает как служба, или даже является консольной. Главное условие - чтобы занимала минимум оперативной памяти. Без фанатизма, конечно. То есть разницы между 1.9Мб и 2.1Мб нет никакой, а вот разница между 100Кб и 10Мб существенная.

То есть нужен какой-то баланс между удобством и минимализмом, но с перекосом в сторону минимализма. Писать самую маленькую программу в мире не нужно (62 байта). Запихивать 3D игру в 1Кб тоже не нужно (mars). Просто не хотелось бы пихать в билд кучу всего подряд на все случаи жизни, что там будет лежать мертвым грузом и не использоваться (или, что ещё хуже, работать вхолостую).

К примеру, какой примерно размер билда может быть у утилиты, которая просто отслеживает двойной щелчок мыши во всех запущенных приложениях? GUI - просто кнопка "reset" и счетчик нажатий, без красивого оформления, с упором на минимализм. По моим прикидкам даже 100Кб будет много, хотя тянуть с собой стандартную библиотеку не зазорно, но всё же слишком жирно для такой простой задачи. А в оперативной памяти, соответственно, какой-нибудь полноценный сборщик мусора здесь тоже будет явно лишним.

Подразумевается, что таких мелких программ может одновременно работать очень много. К примеру, 20 штук (под разные хотелки). И если каждая будет под 100 Мб, то это как-то не круто. Вспоминаются старые добрые времена, когда всем за глаза хватало 640Кб...

Comments

[Игорь]

Вирусы писать надумали?

[dollar]

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

[Владимир Коротенко]

К примеру, какой примерно размер билда может быть у утилиты, которая просто отслеживает двойной щелчок мыши во всех запущенных приложениях? GUI - просто кнопка "reset" и счетчик нажатий, без красивого оформления, с упором на минимализм.

Ну смотрите.
https://docs.microsoft.com/en-us/windows/win32/win...
1 библиотека хук, описана в Platform SDK
2 программа носитель

Библиотека при определенных ключах компилятора выйдет в 4-5 КБ
Программа из одной иконки в трее, 1 диалог бокса займет 15-40 КБ

Язык С, зависимостей никаких, совместимость см по справочнику, но по идее будет работать даже на windows 95.

Сейчас я бы такое не писал.

[dollar]

Программа из одной иконки в трее, 1 диалог бокса займет 15-40 КБ

Откуда столько, если иконка 16х16, и графического оформления в диалоге нет никакого?

Сейчас я бы такое не писал.

А если стоит задача, то на чем бы писали? И какой бы это дало оверхед?

Answer 1

[Hemul GM]

Если хотите минимум требований по ОЗУ попробуйте Delphi (RAD Studio). Ни каких фреймворков и сторонних библиотек. Единственный, самодостаточный exe, использование памяти которого контролируете вы сами.


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

Comments

[dollar]

Интересный вариант. А Delphi разве не умирает, как говорят?
Так Delphi или RAD Studio?
И я так понимаю, что это всё сильно дорогое удовольствие (в рублях), верно?

[Hemul GM]

dollar, RAD Studio CE (Community Edition) - бесплатная. Можешь качать и писать софт хоть на винду, хоть на линь, хоть на мобилки.
Delphi - язык. RAD Studio - среда разработки.

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

[res2001]

Hemul GM, Круто, апликуха с одной кнопкой занимает в памяти 1.3 Мб :-) Вопрос вроде бы был про минимализм.

[Hemul GM]

res2001, так ты прочти внимательнее вопрос и посмотри, какими значениями оперирует автор.
А то, что я показал, "аппликуха" которая сейчас под отладчиком, с иконкой в мегабайт (или более), с подключенным стандартными библиотеками.

[xmoonlight]

Hemul GM, как же все хотят выгнать народ с делфи... Удивляюсь просто)))

Answer 2

[index0h]

Под винду берите c#. То, сколько будет потреблять ресурсов - полностью на вашей совести.

Answer 3

[Владимир Коротенко]

C#,VB, (NET 3 ) рантайм уже вшит во все операционки.

Если хочется экстремально малого объема используйте mfc / QT или для совсем маленьких WinAPI + WTL.
Сразу предупреждаю сам код не занимает место, основное это ресурсы.

Забавно что упомянули клики, писал такое
https://github.com/vkorotenko/mouse

Comments

[Hemul GM]

Qt ещё тот пожиратель ОЗУ, о чем вы?

[Владимир Коротенко]

Hemul GM, По сравнению с остальными не так уж и много.
Сравните с явой или электроном

[Hemul GM]

Владимир Коротенко, с ними вообще нельзя сравнивать. Ява использует вм, а электрон - браузер.

[Владимир Коротенко]

Hemul GM, Net тоже использует виртуальную машину. Правда есть возможность прекомпиляции.
Электрон тоже можно считать виртуальной машиной, есть прекомпиляция, предсказание ветвлений.
Все несколько размыто.

[Hemul GM]

Владимир Коротенко, Mono использует что-то на подобие вм, но это совершенно другое. Электрон использует chromium, который сам по себе использует ОЗУ "мама не горюй". У явы вм - тоже совершенно другое.

[dollar]

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

[Владимир Коротенко]

Hemul GM, Вы таки путаетесь. Net использует промежуточный код, который исполняется на виртуальной машине, даже кстати не на одной, их целая куча.
Ява тоже самое, байт код в виртуальной машине и несколько виртуальных машин на выбор.
Хромиум использует движок V8, там тоже очень и очень хитрые оптимизации.

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

[Hemul GM]

Владимир Коротенко, так как бы я об этом вам и говорю. Я здесь выступаю на за .NET или прочие, я здесь предлагаю использовать Delphi. (Последний ответ на вопрос.)

[#]

Владимир Коротенко, у дотнета jit-компиляция а не ВМ. какой то олух написал в википедии о якобы наливии ВМ у дот нет. тепеь пол мира повторяет

Хромиум использует движок V8, там тоже очень и очень хитрые оптимизации.
Все эти технологии очень близки по скорости к нативному коду, а где то даже и быстрее.

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

[#]

Владимир Коротенко, ps к каменту выше. и извинения ))
https://julialang.org/benchmarks/
как минимум в одном достаточно объемном (хотя не факт что во всем абсолютно объективном ))) исследовании. обгон голого C (без плюсов )), а так же нового претендента на лидерство Julia, в рекурсивном qsot на LuaJIT, был четко зафиксирован ))

[Владимир Коротенко]

#, Кстати один нативный код, с легкостью может быть быстрее другого.

Меняем gcc 4.x на интеловский компилятор и получаем результат.

Answer 4

[АртемЪ]

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

Вспоминаются старые добрые времена, когда всем за глаза хватало 640Кб..

.Тогда и задачи были немного другими.

Comments

[Владимир Коротенко]

От языка, технологий это мало зависит, от IDE вообще не зависит.

Это вы несколько погорячились.
Таскать мышкой контролы и расставлять биндинги самое то.

[АртемЪ]

Владимир Коротенко, Не понял о чем вы.
При чем тут таскание мышкой контролов?

[Владимир Коротенко]

АртемЪ, Приведенная ниже портянка кода соответствует, 1 кнопке на форме.
Так что разница есть.

#region Windows Form Designer generated code

        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {
            this.button1 = new System.Windows.Forms.Button();
            this.SuspendLayout();
            // 
            // button1
            // 
            this.button1.Location = new System.Drawing.Point(495, 245);
            this.button1.Name = "button1";
            this.button1.Size = new System.Drawing.Size(118, 45);
            this.button1.TabIndex = 0;
            this.button1.Text = "button1";
            this.button1.UseVisualStyleBackColor = true;
            // 
            // Form1
            // 
            this.AutoScaleDimensions = new System.Drawing.SizeF(9F, 20F);
            this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
            this.ClientSize = new System.Drawing.Size(800, 450);
            this.Controls.Add(this.button1);
            this.Name = "Form1";
            this.Text = "Form1";
            this.ResumeLayout(false);

        }

        #endregion

[АртемЪ]

Владимир Коротенко, Ну да, приведенная портянка описывает кнопку, в чем проблема то? Не могу понять вашу мысль.

[Владимир Коротенко]

АртемЪ, Я просто создал форму и поместил кнопку.
Все остальное сделала IDE.
И кучу не очевидных вещей, которые высвечиваются в панели рядом.
Так что от IDE много зависит, особенно когда нужно по быстрому накидать интерфейс.

[АртемЪ]

Владимир Коротенко, Понятно о чем вы.
Но ничего лишнего IDE не делает в основном. Кода побольше немного и только. Ничего тяжелого она не подключит.
А если и делает - можно оптимизировать.

[Владимир Коротенко]

АртемЪ, Можно, но затратно для маленького проекта.
Плюс еще нужно знать весь неймспейс System.Windows.Forms.
Если работаешь постоянно то это в голове как то удерживается, а так постоянно справочник держать открытым. Так себе занятие. Это еще при том что у Microsoft одна из лучших документаций.

Answer 5

[Saboteur]

Писать самую маленькую программу в мире не нужно (62 байта).

Что-то слишком много как для самой маленькой программы в мире. Есть же гораздо меньше.

К примеру, какой примерно размер билда может быть у утилиты, которая просто отслеживает двойной щелчок мыши во всех запущенных приложениях?
GUI - просто кнопка "reset" и счетчик нажатий, без красивого оформления, с упором на минимализм. По моим прикидкам даже 100Кб будет много, хотя тянуть с собой стандартную библиотеку не зазорно, но всё же слишком жирно для такой простой задачи.

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

Подразумевается, что таких мелких программ может одновременно работать очень много. К примеру, 20 штук (под разные хотелки). И если каждая будет под 100 Мб, то это как-то не круто. Вспоминаются старые добрые времена, когда всем за глаза хватало 640Кб...

Так напишите одну программу с 20-ю хотелками и все.

В старые добрые времена 640 кб никому не хватало. Вдобавок в те времена, windows была совсем не многозадачной и не умела все то, что сейчас происходит. Даже банально работа с графикой - есть разница между 320x200x256 и 1920x1024x65536.

По языкам - не суть важно. На самом деле на каждом языке можно писать с умом и оптимизацией. Но для ваших задач - нет смысла сейчас выбирать специализацию. Ваши программы очень простые. Попробуйте написать их на c++, на C# и на java/kotlin и посмотрите потом, какой язык вам больше подходит. Не бросайте все три после первой же программы. Попробуйте все-таки развиваться некоторое время во всех трех. Так поймете больше разных концепций, и собственно почему инструмент выбирают под задачу.

Comments

[АртемЪ]

В старые добрые времена 640 кб никому не хватало.

Хватало! Всем и для всего. В частности 32кб это было реально круто!

Вдобавок в те времена, windows была совсем не многозадачной

Вы серьезно?
Не было виндовс в те времена, ни многозадачной, ни однозадачной. Вообще не было!
DOS - дисковая операционная система!

[Saboteur]

АртемЪ, Не очень понятно про какие времена вы упоминаете.
Разговор про 640 кб, а это уже начало девяностых, то есть вполне существовал windows, даже вроде 2.0. И требовал он гораздо меньше 640 кб для запуска.

Про 32 кб, этого хватало разве что для dos 1.0, и то, при этом что-либо загрузить уже было почти нереально, поэтому давайте все-таки про времена 1990+

[АртемЪ]

Saboteur,

Не очень понятно про какие времена вы упоминаете.

Начало 80х прошлого века.
Время выпуска первой операционной системы компании майкрософт - MS DOS 1
Именно тогда 640 кб казались огромной цифрой и было непонятно куда же больше.

А уже в начале 90х появились первые ОС с графическим интерфейсом, в частности win 3 - к тому моменту уже стало ясно что нужно хотя бы пару мегабайт оперативной памяти для работы.

Answer 6

[#]

самый компактный и быстрый код - ассемблер
самая компактная "IDE" - notepad. хотя и это не предел. есть консольные редакторы. даже под винду

вы уж определитесь с хотелками. под винду нет инструмента лучше Visual Studio (а современный инсталятор отлично выбирает хотелки). если у вас слишком слабый комп - очень интересный инструмент Visual Studo Code (вот только исользует node.js и засирает систему кучами кешей npm, даже для собственного функционирования) зато наверное уже давно рекордсмен по количеству поддерживаемых языков (но плагины как правило и являются модулями npm)

ps на сколько мне известно, это последняя версия официального ассемлера МС - https://www.masm32.com/ там даже какая то своя IDE есть
но на masm свет клином не сошелся - https://www.nasm.us/
и для nasm есть даже очень легковестная ide, ссылка в гугл, по тому что там еще и статься с хабра вылетает - https://www.google.com/search?client=firefox-b-d&e...
.. и вообще, ассемблеров, как собак не резаных.. в чем глубинные отличия, кроме библиотек макросов, что логично, мне как правило даже и не понятно ))

pps Visual Studio Community редакция абсолютно бесплатна, по окончании 30 дневного трила, если не ошибаюсь, надо просто зарегистрироваться. лицензия (довльно дешевая) требуется для публикации приложений в "магазин" МС. она у меня есть давно, по этому что делать тем у кого ее нет - не подскажу

Visual Studo Code, а так же подавляющее большинство плагинов к ней, беспалтны абсолютно

Comments

[Saboteur]

самый компактный и быстрый код - ассемблер

Уже не факт, современные компиляторы уже разбираются в деле больше, чем джуниоры и мидеры.
Ну и компактный код - скриптовые языки еще более компактные =)

[#]

Saboteur, начнем с конца:

Ну и компактный код - скриптовые языки еще более компактные =)

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

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

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

[Saboteur]

#,

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

echo a

6 байт. Тоже самое на ассемблере сколько займет? Один заголовок .exe или ELF файла займет больше.

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

Именно. На любом языке, в том числе и на ассемблере.

[#]

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

[#]

Saboteur, и да, я в курсе, что некоторые скриптовые языки, на некоторых тестах, вполе себе догоняют оптимизированнй c/c++
https://julialang.org/benchmarks/
хм.. Владимир Коротенко, согласно только что упомянутой диаграмме сравнений, внужден смягчит категоричность некоторых выссказываний - прецеденты обгона скриптовыми языками, нативных c/c++ (по инерции считающихся эталонами ерфоманса) имеют место быть. приношу извинения ))

[Saboteur]

#, Основная проблема, что смотря на языки программирования, особенно типа ассемблера, программисты зачастую забывают, что кроме алгоритмов, производительности, сложности разработки существует тысячи других задач, где важна простота, надежность, обратная совместимость.
И начинают выискивать примеры с JS или python, чтобы как-то сравнить их со своими любимыми инструментами.
Я вообще не уверен, что JS можно назвать языком для написания скриптов. Есть исключения (работа с базами данных), но в основном сейчас на JS пишут именно программы.
Скрипты - это вещи, которые предназначены для автоматизации, склеивания разных частей.
Шелл скрипты (тысячи инсталляторов, бэкапы, автоматизация, администрирование, метрики), бейсики, cmd/powershell - это скрипты.
А питон и JS, и даже perl ушли давно перешли из языков для скриптов в мир большой разработки

[#]

Saboteur, спасибо доктор ))

[#]

Saboteur,.. только вы збыли классифицировать нынешний статус Lua ;))
ps про tarantul и webapp server на базе nginx+LuaJit напомнить? ;)))

[#]

Saboteur,

Шелл скрипты (тысячи инсталляторов, бэкапы, автоматизация, администрирование, метрики), бейсики,

- sh и perl тут потеснены именно питоном, но моим скромным наблюдения, до вытеснения, еще как до китая пешком ))
- бейсики.. да это отдельная песня, с нотками VBA, даже не побоюсь (вру, побоюсь) этох букв 1C (тут в пору озвучку добавить фонфары, или литавры какие) ))
- powershell.. ну на нем уже откалываю коленца, если МС не ослабит маркетинг, и допилит реально удобный и кросс платформенный ps3, то "коленец" то со временем может стать вполне себе не мало ))

ps все смешалось в доме Обломовых (с).. ;))
pps и да - MS vbs еще ни кто не увольнял )) мало того, под MS ScriptHost есть вполне себе гуевые приложения, ессно это в основном инсталяторы/конфигуряторы чего либо. практически полностую в секторе продукции MS корпоративного назначения. и обычно не для мелкой шпаны, для крупных таких хозяйств ))

[dollar]

Saboteur, насколько я знаю, понятие "скрипты" отличается тем, что там присутствует в том или ином виде интерпретация. А с учетом модных jit и пр. скриптами можно называть всё, что распространяется в исходных кодах (для непосредственного запуска).

В контексте вопроса проблема здесь в том, что скрипт тянет с собой интерпретатор или что-то такое, в общем тяжелое. Поэтому скрипты - ок, если в системе с большой вероятностью есть компонент или программа для него, и только если запуск одноразовый или не ест много памяти. Скажем, JS - ок, потому что браузер практически у всех есть. Шелл - тоже ок. Однако шелл скрипт разве может создать иконку в трее или создать окно с кнопкой? У JS, соответственно, тоже ограничения на доступ к ресурсам компьютера. И оба варианта тянут с собой некое окружение для запуска и работы. Для JS это 25Мб минимум, даже если нужно просто посчитать 2+2. Многовато для мини-программки, имхо.

[dollar]

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

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

[#]

dollar,

насколько я знаю, понятие "скрипты" отличается тем, что там присутствует в том или ином виде интерпретация.

ну тут я скорее соглашусь ))

к пимеру штатные инструменты F# позволяют писать именно скрипты. а при владении языком - просто чумовые..
в C# допилили аналогичную штуку в Roslin, но года через 2-3 только довели до ума. и то не совсем. по удобству она ну очень уступает. с одной стороны, это элемент фреймворка а не SDK или даже студии (на сколько я помню, могу попутать преувеличить оптимизм). но в скриптовом шарпе (от MC, а не поделки что сначала быстренько компилят, а потом исполняют) там жутко все портит факт, что по сути невозможен импорт namespace, все библиотечные классы надо выписывать в полной классификации. что убивает скриптовый потенциал на корню. букв слишком много становится ))

В любом случае Lua не вариант, конечно же, т.к. он не самостоятелен и требует обертки другим языком.

ну что вы:
- LuaJit и с шашкой на голо покорять мир )))
- в Far Lua встроенный скриптовый язый. вобще у lua довльно богаты выбор сопособов куда встроить
ну и повторю (я иногда пишу постскрипутмы к каментам с большим отрывом, то есть их могу просто не замечать за давностью камента)

..у насто противостояние что интрепретируемый язый != скриптовый язык
- js чаще всего ассоциируют с node.js и/или браузерами. и в этих средах js изолируется от полного доступа к системе. что и правильно, но

pps и да - MS vbs еще ни кто не увольнял )) мало того, под MS ScriptHost есть вполне себе гуевые приложения, ессно это в основном инсталяторы/конфигуряторы чего либо. практически полностую в секторе продукции MS корпоративного назначения. и обычно не для мелкой шпаны, для крупных таких хозяйств ))

пусть это и другой диалект, но это js и абсолютно скриптовый
второй аргумент был

примеры с JS или python, чтобы как-то сравнить их со своими любимыми инструментами. ... А питон и JS, и даже perl ушли давно перешли из языков для скриптов в мир большой разработки

контраргумент, но правда косвенный. по тому что про Lua

ps про tarantul и webapp server на базе nginx+LuaJit напомнить? ;)))

как то так... простите за многословие (и опечатки ))

[Saboteur]

dollar,

В контексте вопроса проблема здесь в том, что скрипт тянет с собой интерпретатор или что-то такое, в общем тяжелое.

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

Что же касается иконок в трее - вы видимо не представляете возможностей скриптов и тех же самых вызовов системных функций.
Шелл скрипт вряд ли сделает иконку в виндовс, потому что шелл скрипт - это парафия *nix, он умеет много чего в родной среде. А для Windows родной PowerShell - он легко может и иконку в трее сделать и окошко с кнопкой. И вообще, у вас впечатление, что велосипеды это какая-то халтура. Вы даже не представляете какие костыли и велосипеды у компилируемых продуктов.

[Saboteur]

@mindtester, только вы збыли классифицировать нынешний статус Lua ;))

Lua - библиотека для встраивания удобный готовый интерпретатор скриптового языка внутрь своего продукта, чтобы не писать свой "велосипед"

- sh и perl тут потеснены именно питоном, но моим скромным наблюдения, до вытеснения, еще как до китая пешком ))

sh нельзя сравнивать с питоном. sh, cmd и powershell - это не просто скриптовые языки. это консольная оболочка операционных систем.
perl - да, его сильно вытеснил питон. А shell/cmd/powershell никогда и не занимали эту нишу. Они просто существуют вне времени, пока существуют операционные системы.
Языки, которые сильно изменили своей альма матер, на мой взгляд это visualbasic, javascript и тот же LUA.

- бейсики.. да это отдельная песня, с нотками VBA, даже не побоюсь (вру, побоюсь) этох букв 1C (тут в пору озвучку добавить фонфары, или литавры какие) ))
- powershell.. ну на нем уже откалываю коленца, если МС не ослабит маркетинг, и допилит реально удобный и кросс платформенный ps3, то "коленец" то со временем может стать вполне себе не мало ))

ps все смешалось в доме Обломовых (с).. ;))
pps и да - MS vbs еще ни кто не увольнял )) мало того, под MS ScriptHost есть вполне себе гуевые приложения, ессно это в основном инсталяторы/конфигуряторы чего либо. практически полностую в секторе продукции MS корпоративного назначения. и обычно не для мелкой шпаны, для крупных таких хозяйств ))

[dollar]

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

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

Answer 7

[res2001]

Для реализации требуемого функционала можно вообще не использовать никаких библиотек - все обеспечивает ОС API (для никсов GUI - не входит в API, предоставляемое ядром, но это не играет роли).
Максимально маленький размер exe и потребляемой памяти можно получить на С/С++. Си чуть более компактен и быстр.
Писать на голом ОС API достаточно долго и трудоемко, и код будет максимально далек от кросс-платформенности (хотя в вопросе про это речь не идет). Но это будет очень хороший опыт и это достаточно интересно на небольших проектах.
Поэтому, если все же есть какие-то сроки, то следует использовать библиотеки, ускоряющие разработку. Конечно, библиотеки - это прослойка между ОС API и приложением и это увеличивает и объем исполняемого файла и объем потребляемой памяти. Но тут всегда нужно принимать какой-то компромис.
Для GUI под винду можно использовать WTL - это компактная ООП надстройка над виндовым GUI, разработана микрософт предоставляется в исходниках (по крайней мере когда я последний раз имел с ней дело). WTL - это по любому С++. Хватает и других библиотек для GUI.

На счет IDE - можно использовать любую - это не влияет на количество потребляемой приложением памяти.

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

Answer 8

[xmoonlight]

Delphi7 - 7кб консольный exe-шник.

Comments

[dollar]

А с кнопкой и помещением в трей?

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

[xmoonlight]

dollar, трэй - это иконка + api вызов: там больше на 20кб максимум станет.

И если нужна функция из какой-то библиотеки, то в память будет загружена она вся, даже если нужна всего одна функция?

Смотря какая библиотека: статическая или динамическая.
Статика - в оперативке полностью либа.
Динамика - только используемые функции загрузит при запуске exe-шника.