Ошибаетесь. Разрабатывал, хоть и не так много, как под Windows.
Ну опишите открытым текстом, что вашим приложениям мешает жить на линукс-машины без завёртывания в контейнер?
И, каким бы ни был ответ, почему вместо допиливнаия линукса (что было бы идеологически верным) лепят нашлёпку поверх недопиленного линукса и ещё и радуются этому?
И как тогда по вашему существовал мир до создания докера? Как кромешный ад и ужас? Это мне напоминает «ощущение» у неофитов, что 100 лет назад мир в принципе был чёрно-белым.
Непонятно только, почему этим так называемым разработчикам приложений так «зашла» идея заворачивать приложения в изолированных ящиках.
Может потому, что они настолько криворукие разработчики, что не могут написать приложения, которые бы не мешали работе друг-друга?
В 2000-х была популярна шутка про начинающих разработчиков, которые пишут приложения, которые нигде больше не запускаются, кроме как на компе своего создателя. Такое ощущение, что весь тот докер про это.
Если же всё дело в изоляции, то чем системные механизмы изоляции не устраивают? И если все-таки не устраивают, с какого перепугу проблему изоляции прикладных программ решает другая прикладная программа, а не решается это на уровне ОС?
В каком виде вам нужен пруф, чтобы он считался пруфом? Если мой комментарий о том, что вещи устроены так, это не пруф, то будет ли моя статья об этом же самом считаться пруфом?
Я единолично разреверсил VB/VBA (по крайней мере эту его часть), задокументировал все типы узлов синтаксического дерева, организцию структур, типы сущностей RPN-подобного представления кода (дерево вскоре после своего построения конвертируется в линейную RPN-like цепочку из 16-битных сущностей и именно эти линейные структуры долговременно хранятся в памяти IDE, именно они представляют код и именно из них регенерируется текстовое представление кода, когда его нужно отрисовать на экране, скопировать в буфер обмена или сохранить в файл.
Вот вам пруф, к достоверности которого вы явно не прикопаетесь:
Откройте VB/VBA и в IDE напишите какой-нибудь код, например такой:
If Minute(Now) Mod 2 = 0 Then MsgBox "Hello World!" Else MsgBox "Goodbye!"
Теперь присоединитесь к процессу IDE отладчиком и попробуйте в памяти процесса найти эту строчку. Вы её там не найдёте. Ни в виде ANSI-строки, ни в виде UCS2-строки, ни в виде UTF8-строки. Ни в каком виде.
Точнее, есть шанс, что вы её случайно найдёте в памяти, но это просто просто мусор — незанулённый и никем более не используемый регион памяти. Можете затереть в таком случае всю найденную строку буквами «Ы», вернуться в IDE и строка с If-ом как была, так и останется.
А, ну окей, скажете вы, наверное IF как структура как-то хитро представляется, но вот условие IF-а, then-clause или else-clause должны храниться как строка.
Нет, тоже мимо.
Подстроку «Minute(Now) Mod 2 = 0», подстроку «MsgBox "Hello World!"» и подстроку «MsgBox "Goodbye!"» вы тоже не найдёте. Их не будет в памяти. А если вдруг и будет, то это мусор, перезатирение которого чем-либо иным ни на что не влияет.
Гораздо больше подробностей о том, как это устроено под капотом, можно прочитать в этом комменте
Конечно, дизайн языка должен соответствовать такой концепции. Но не нужно писать «этого не может быть, потому что этого не может быть никогда», в то время как подобное десятилетиями работало (и продолжает работать, или в современных Офисах выпилили VBA? — простите, я не слежу). Такие высказывания говорят скорее о малом кругозоре. В мире чего только не бывает.
А что значит само по себе выражение «передача метода в язык автоматическим управлением»?
В COM у метода могут быть аттрибуты (hidden, restricted), из из языка типа VB вы этот метод не увидите или не вызовите.
А вот что есть в спецификации COM, так это запрет на то, чтобы вызывать AddRef у одного интерфейса, а комплиментарный ему Release у другого. То есть, хотя 90% имплементаций имеют один счётчик ссылок «на объект», согласно спецификации у каждого интерфейса объекта (а интерфейсов у объекта может быть много) должен быть свой счётчик ссылок, и каждый интерфейс может порождаться/уничтожаться независимо от других.
Соответственно, вызывая AddRef или Release вы не управляете временем жизни объекта, вы управляете временем жизни конкретного интерфейса. Другое дело, что имплементация в 90% (а то и больше) случаев в угоду упрощения скатывается до единой для всех реализации AddRef/Release и единому счётчику ссылок. Более того, если реализовывать COM-объект на C++ как C++-класс, то по другому и не получится сделать, не прибегая к извратам.
Боюсь, я несколько подзабыл такие материи, как интеграция с Visual Basic (для этого же нужны диспинтерфейсы?), поэтому поправьте, если что-то не так.
Нет, не для этого. Visual Basic прекрасно может работать с объектами, не поддерживающими IDispatch. И с другой стороны, хотя любой экземпляр класса, написанного на VB, будет поддерживать IDispatch, вы прекрасно можете работать с такими объектами из других языков, не поддерживающими IDispatch.
Так что нет, IDispatch нужен не для интеграции с VB, он нужен для позднего связывания. А вот для VBScript он конечно же нужен, потому что там априори всё связывание — позднее, в момент интерпретации скрипта.
Легко — именно так работает IDE классического VB и VBA. Она вообще не хранит код как текст. Вы его не нацдёте в памяти процесса. Даже в виде отдельных строк. И у неё вообще нет проблем с представлением синтаксически некорректных данных — просто путём введения отдельной сущности для представления некорректных стейтментов.
Для вас, автор, это, возможно будет откровением. Ваша идея не нова. Наверное это грустная новость, но приятная новость в том, что я тоже считаю такой подод классным
Так вот, именно так устроен Visual Basic и VBA. Классический VB, а не дотнет, например VB6. Код перестает быть плейтнекстом в момент загрузки с диска. Дальше IDE работает с бинарными графоподобными и RPN-подобнымм данными. Для отображения кода на экране он воссоздаются на лету — только те строки, которые нужно отрисовать.
Всем злопыхателем, которые в статье написали, что идея неудачная и её не реализовать и она спотыкнётся на синтаксически некорректных данных можете приводить это как пример и как опровержение.
В этом комменте собраны все когнитивные ошибки, какие только можно. Начиная с «ошибки выжившего»...
Судить по открытому окну это худшее, что можно придумать. Гораздо достовернее иметь приятеля ПТУ-шника, который рассказывает, как нежные прецизионные вещи забиватся с помощью кувалды и какой-то матери. Из раза в раз, а не в виде редчайшего исключения.
Ещё один хорой способ делать суждения: это посмотреть на множество машин после местных владельцев (а не свежепригнанных с Европы): количество синей изоленты, обходов и упрощения штатных систем, и прочего колхоза зашкаливает.
Но нет, мы будем судить по виду из окна. Ведь каждая увиденная в окне машина гарантированно прошла через ПТУ-шника, и над каждой такой левитирует светящийся нимб, который тождественнен тому, что эта машина дальше будет долго и благополучно ездить, без шанса скорой поломки, без риска для безопасности.
И что, любой человек, который может в ремонт ноутбуков, способен разрабатывать GNSS? С их гигагерцовыми сигналами и прочей СВЧ-магией?
Наверное в постсоветском мире это и правда дешелвле: но это только доказывает мой поинт — оно дешевле, потому что людей, способных на что-то такое, немного, а задач для них около нуля. Поэтому они готовы разрабатывать GNSS за еду. Иначе по заклнам рынка это обходилось бы дороже, чем с Китая.
Ну да, особенно на фоне того, что технику делают катастрофически трудноремонтируемымой.
Недавний пример: чип на материнской плате, в который зашит криптоключ, и этот чип общается с другими чипами, и криптоключ используется для дешифровки. Оный чип сгорел. Если заменить его на новый, что само по себе не просто, ибо БГА, то ничего не заработает, потому как без наличия криптоключа взаимодействия с соседними чипами не получится.
Повторение — мать учения!
Чем больше окурков, тем меньше голов, ещё способных эффективно работать.
А почему очень больно?
Этот лозунг больше бы подошёл Джаве, а не системе контейнеризации.
А у оно не run anywhere, а работает на линуксе в контейнере. И что мешает ему работать точно так же на линуксе без контейнера?
Ошибаетесь. Разрабатывал, хоть и не так много, как под Windows.
Ну опишите открытым текстом, что вашим приложениям мешает жить на линукс-машины без завёртывания в контейнер?
И, каким бы ни был ответ, почему вместо допиливнаия линукса (что было бы идеологически верным) лепят нашлёпку поверх недопиленного линукса и ещё и радуются этому?
И как тогда по вашему существовал мир до создания докера? Как кромешный ад и ужас? Это мне напоминает «ощущение» у неофитов, что 100 лет назад мир в принципе был чёрно-белым.
Непонятно только, почему этим так называемым разработчикам приложений так «зашла» идея заворачивать приложения в изолированных ящиках.
Может потому, что они настолько криворукие разработчики, что не могут написать приложения, которые бы не мешали работе друг-друга?
В 2000-х была популярна шутка про начинающих разработчиков, которые пишут приложения, которые нигде больше не запускаются, кроме как на компе своего создателя. Такое ощущение, что весь тот докер про это.
Если же всё дело в изоляции, то чем системные механизмы изоляции не устраивают? И если все-таки не устраивают, с какого перепугу проблему изоляции прикладных программ решает другая прикладная программа, а не решается это на уровне ОС?
В каком виде вам нужен пруф, чтобы он считался пруфом? Если мой комментарий о том, что вещи устроены так, это не пруф, то будет ли моя статья об этом же самом считаться пруфом?
Я единолично разреверсил VB/VBA (по крайней мере эту его часть), задокументировал все типы узлов синтаксического дерева, организцию структур, типы сущностей RPN-подобного представления кода (дерево вскоре после своего построения конвертируется в линейную RPN-like цепочку из 16-битных сущностей и именно эти линейные структуры долговременно хранятся в памяти IDE, именно они представляют код и именно из них регенерируется текстовое представление кода, когда его нужно отрисовать на экране, скопировать в буфер обмена или сохранить в файл.
Вот вам пруф, к достоверности которого вы явно не прикопаетесь:
Откройте VB/VBA и в IDE напишите какой-нибудь код, например такой:
Теперь присоединитесь к процессу IDE отладчиком и попробуйте в памяти процесса найти эту строчку. Вы её там не найдёте. Ни в виде ANSI-строки, ни в виде UCS2-строки, ни в виде UTF8-строки. Ни в каком виде.
Точнее, есть шанс, что вы её случайно найдёте в памяти, но это просто просто мусор — незанулённый и никем более не используемый регион памяти. Можете затереть в таком случае всю найденную строку буквами «Ы», вернуться в IDE и строка с If-ом как была, так и останется.
А, ну окей, скажете вы, наверное IF как структура как-то хитро представляется, но вот условие IF-а, then-clause или else-clause должны храниться как строка.
Нет, тоже мимо.
Подстроку «
Minute(Now) Mod 2 = 0», подстроку «MsgBox "Hello World!"» и подстроку «MsgBox "Goodbye!"» вы тоже не найдёте. Их не будет в памяти. А если вдруг и будет, то это мусор, перезатирение которого чем-либо иным ни на что не влияет.Гораздо больше подробностей о том, как это устроено под капотом, можно прочитать в этом комменте
https://habr.com/ru/articles/582566/comments/#comment_23578554
трёхлетней давности. Там и с примерами того, как те или иные конструкции кодируются и гораздо больше.
И вот тут продолжение того коммента: https://habr.com/ru/articles/582566/comments/#comment_23589108
Конечно, дизайн языка должен соответствовать такой концепции. Но не нужно писать «этого не может быть, потому что этого не может быть никогда», в то время как подобное десятилетиями работало (и продолжает работать, или в современных Офисах выпилили VBA? — простите, я не слежу). Такие высказывания говорят скорее о малом кругозоре. В мире чего только не бывает.
А что значит само по себе выражение «передача метода в язык автоматическим управлением»?
В COM у метода могут быть аттрибуты (hidden, restricted), из из языка типа VB вы этот метод не увидите или не вызовите.
А вот что есть в спецификации COM, так это запрет на то, чтобы вызывать AddRef у одного интерфейса, а комплиментарный ему Release у другого. То есть, хотя 90% имплементаций имеют один счётчик ссылок «на объект», согласно спецификации у каждого интерфейса объекта (а интерфейсов у объекта может быть много) должен быть свой счётчик ссылок, и каждый интерфейс может порождаться/уничтожаться независимо от других.
Соответственно, вызывая AddRef или Release вы не управляете временем жизни объекта, вы управляете временем жизни конкретного интерфейса. Другое дело, что имплементация в 90% (а то и больше) случаев в угоду упрощения скатывается до единой для всех реализации AddRef/Release и единому счётчику ссылок. Более того, если реализовывать COM-объект на C++ как C++-класс, то по другому и не получится сделать, не прибегая к извратам.
Нет, не для этого. Visual Basic прекрасно может работать с объектами, не поддерживающими IDispatch. И с другой стороны, хотя любой экземпляр класса, написанного на VB, будет поддерживать IDispatch, вы прекрасно можете работать с такими объектами из других языков, не поддерживающими IDispatch.
Так что нет, IDispatch нужен не для интеграции с VB, он нужен для позднего связывания. А вот для VBScript он конечно же нужен, потому что там априори всё связывание — позднее, в момент интерпретации скрипта.
Как, как да как.
Легко — именно так работает IDE классического VB и VBA. Она вообще не хранит код как текст. Вы его не нацдёте в памяти процесса. Даже в виде отдельных строк. И у неё вообще нет проблем с представлением синтаксически некорректных данных — просто путём введения отдельной сущности для представления некорректных стейтментов.
Для вас, автор, это, возможно будет откровением. Ваша идея не нова. Наверное это грустная новость, но приятная новость в том, что я тоже считаю такой подод классным
Так вот, именно так устроен Visual Basic и VBA. Классический VB, а не дотнет, например VB6. Код перестает быть плейтнекстом в момент загрузки с диска. Дальше IDE работает с бинарными графоподобными и RPN-подобнымм данными. Для отображения кода на экране он воссоздаются на лету — только те строки, которые нужно отрисовать.
Всем злопыхателем, которые в статье написали, что идея неудачная и её не реализовать и она спотыкнётся на синтаксически некорректных данных можете приводить это как пример и как опровержение.
Господи... Во что они превращают C++...
В этом комменте собраны все когнитивные ошибки, какие только можно. Начиная с «ошибки выжившего»...
Судить по открытому окну это худшее, что можно придумать. Гораздо достовернее иметь приятеля ПТУ-шника, который рассказывает, как нежные прецизионные вещи забиватся с помощью кувалды и какой-то матери. Из раза в раз, а не в виде редчайшего исключения.
Ещё один хорой способ делать суждения: это посмотреть на множество машин после местных владельцев (а не свежепригнанных с Европы): количество синей изоленты, обходов и упрощения штатных систем, и прочего колхоза зашкаливает.
Но нет, мы будем судить по виду из окна. Ведь каждая увиденная в окне машина гарантированно прошла через ПТУ-шника, и над каждой такой левитирует светящийся нимб, который тождественнен тому, что эта машина дальше будет долго и благополучно ездить, без шанса скорой поломки, без риска для безопасности.
Да.
Нет, нет и ещё раз нет.
И что, любой человек, который может в ремонт ноутбуков, способен разрабатывать GNSS? С их гигагерцовыми сигналами и прочей СВЧ-магией?
Наверное в постсоветском мире это и правда дешелвле: но это только доказывает мой поинт — оно дешевле, потому что людей, способных на что-то такое, немного, а задач для них около нуля. Поэтому они готовы разрабатывать GNSS за еду. Иначе по заклнам рынка это обходилось бы дороже, чем с Китая.
Ну да, особенно на фоне того, что технику делают катастрофически трудноремонтируемымой.
Недавний пример: чип на материнской плате, в который зашит криптоключ, и этот чип общается с другими чипами, и криптоключ используется для дешифровки. Оный чип сгорел. Если заменить его на новый, что само по себе не просто, ибо БГА, то ничего не заработает, потому как без наличия криптоключа взаимодействия с соседними чипами не получится.
Ноутбук Делл.
Чем и где зарабатывать? Разработкой электроники?
Придумайте мне задачу, и я покажу, что китайцы уже давно сделали это и продают...
>нормальную 64-битную версию x86
IA-64 это не 64-битная версия x86, это VLIW.
Без AMD, глядишь, Интел бы придумала нормальную 64-битную версию x86, а не то, что сейчас известно под именем amd64 aka x86-64.
Только не спрашивайте, что не так с x86-64.