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

Реально ли прикрутить SIP телефонию в electron? У кого-нибудь был опыт с этим?

а что сложного

вы хотите в электроне интерфес сделать?

Вот представьте - вы хотите из-под electron-based приложения получить фактическую архитектуру операционной системы. Не предполагаемую, не ожидаемую архитектуру под которой будет запускаться ваш билд, а фактическую. Чтобы уметь чекать моменты когда x86 билд запущен на x86_64 и arm64. Как бы вы это сделали?

Привет, если я правильно понял, то должно хватать process.arch и process.platform

Это тоже не выгорит, т.к. process.arch и process.platform (как и их алиасы os.arch() и os.platform()) т.к. они возвращают таргетную архитектуру билда (т.к. то, под что собирался билд) но не то, где он запущен фактически

Хмм, разве таргетную они возвращают?

https://nodejs.org/docs/latest-v22.x/api/process.html#processarch > The operating system CPU architecture for which the Node.js binary was compiled

И ещё какие-нибудь системные энвы могут быть, на которые можно опираться

так вот

ну первое что приходит на ум - через exec

Есть решение задачи?)

https://nodejs.org/docs/latest-v22.x/api/process.html#processarch > The operating system CPU architecture for which the Node.js binary was compiled

Я просто понял, что у меня есть некий баг)0

Я нашел и зарепортил этот баг - в итоге это marked as not planend потому что nodejs выпиливает поддержку x86 В будущем LTS релизе :\

И я понимаю - похоже что я сам по себе в решении этого вопроса. Ну ок, копаю дальше. И узнаю, что для каждого процесса в Session 1 винде (т.е. для всех пользовательских exe'шников) сеттится переменная окружения PROCESSOR_ARCHITECTURE), как @GeorgKrom уже спойлернул))) Алелуйя! Вот на нее и завяжемся чтобы разрузить багованную апишку ноды на винде. Но как всегда, есть ньюанс...

Насколько я смотрел при каких-то сценариях её может не быть или там ещё нескольких других envов

Именно! В случае, когда ваше x86 приложение запускается на x86_64 или arm64 операционке - в PROCESSOR_ARCHITECTURE хардкодится значение x86, а **настоящее* значение пеезжает в PROCESSOR_ARCHITEW6432. Дока M$ четко об этом говорит (https://learn.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details#environment-variables) Но чего она вам не скажет, так это то, что что переменная PROCESSOR_ARCHITECTURE на Windows для arm64 для сборок под x86_64 имеет значение AMD64, не соответствующее фактической архитектуре операционной системы. Это прозвучит абсолютно контринтуитивно и противоречашее здравому смыслу, но такова картину. Задержитесь на этом абзецце пару минут и подумайте над абсурдностью ситуации.

Вот бы мне такое рассказал кто-нибудь, когда я это расследование год назад проводил. Хуже было только понять, что нельзя .dmg файлы через телегу перекидывать, иначе они с каким то шансом могут сломаться (меня спасли тут в чате)

Вот бы мне такое рассказал кто-нибудь, когда я это расследование год назад проводил. Хуже было только понять, что нельзя .dmg файлы через телегу перекидывать, иначе они с каким то шансом могут сломаться (меня спасли тут в чате)

И это приводит нас к следующей проблеме - мы не можем в полной мере доверять ни апишке ноды, ни переменным среды винды потому что они не всегда работают корректно. Но мы можем с ними жить, если научимся достоверно чекать что фактическая архитектура винды - arm64. И тут у нас есть целых два варианта: 1) Чекнуть что есть переменная process.env["ProgramFiles(Arm)"]. Да, это смешно, но способ рабочий. 2) Юзнуть малоизвестную апишку electron'а, которую они забиндили в код хромиума app.runningUnderARM64Translation: https://www.electronjs.org/docs/latest/api/app#apprunningunderarm64translation-readonly-macos-windows (имплеменатция в хромиуме: https://source.chromium.org/chromium/chromium/src/+/main:base/win/windows_version.cc;bpv=1;bpt=1;l=132?gsn=IsRunningEmulatedOnArm64&gs=KYTHE%3A%2F%2Fkythe%3A%2F%2Fchromium.googlesource.com%2Fcodesearch%2Fchromium%2Fsrc%2F%2Fmain%3Flang%3Dc%252B%252B%3Fpath%3Dbase%2Fwin%2Fwindows_version.cc%23pl97LyU6QuQZ9YV8bvY2wN5mOhLEbOp8M-1AMM8GYEw)

И вот теперь... Похоже что мы готовы тестить. Мы покрыли все известные нам кейсы и готовы прогнать боевой тест. Но Parallels Desktop, через который мы на arm маке виртуализируем arm Windows 11 (потому что нет на руках реальность устройства на win arm) говорит нам: "Не так бысто чувак". И через os.machine() возвращает нам строку unknown, которая ВООБЩЕ НИГДЕ НЕ ДОКУМЕНТИРОВАНА, НИ ОПИСАНА В КОДЕ НОДЫ Это приводит нас к тому, что мы руками пишем при unknown долбится в озвученные ранее переменные среды потому что "а чо делать то?"

И вот теперь... Похоже что мы готовы тестить. Мы покрыли все известные нам кейсы и готовы прогнать боевой тест. Но Parallels Desktop, через который мы на arm маке виртуализируем arm Windows 11 (потому что нет на руках реальность устройства на win arm) говорит нам: "Не так бысто чувак". И через os.machine() возвращает нам строку unknown, которая ВООБЩЕ НИГДЕ НЕ ДОКУМЕНТИРОВАНА, НИ ОПИСАНА В КОДЕ НОДЫ Это приводит нас к тому, что мы руками пишем при unknown долбится в озвученные ранее переменные среды потому что "а чо делать то?"

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

Осталось теперь разобраться с тем же самым на macOS

Если там, конечно, всё также плохо, я сам не смотрел вообще

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

Ещё для затравочки в 2 предложениях 1 прикол расскажу. При подключении по рдп на винде всегда тянется последний сохраненный пароль и логин, если ты включил в конфиге рдп параметр prompt for credentials, даже если ты его уже поменять хочешь. Просто потому что так mstsc.exe работает и ему вообще плевать что ты там хочешь сделать на самом деле. Поэтому нашёлся костыль тысячелетия: просто ходить и в Windows Credentials Manager для нужного тебе gateway при подключении подставлять туда логин и пароль, а потом его стирать )))))

Ещё для затравочки в 2 предложениях 1 прикол расскажу. При подключении по рдп на винде всегда тянется последний сохраненный пароль и логин, если ты включил в конфиге рдп параметр prompt for credentials, даже если ты его уже поменять хочешь. Просто потому что так mstsc.exe работает и ему вообще плевать что ты там хочешь сделать на самом деле. Поэтому нашёлся костыль тысячелетия: просто ходить и в Windows Credentials Manager для нужного тебе gateway при подключении подставлять туда логин и пароль, а потом его стирать )))))

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

А на маке вообще это ничо не работает, даже с установленным приложением от Microsoft для рдп, они просто половину параметров игнорируют по непонятной причине

:D

Я боюсь что и это решение не бех изъянов

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

почему бы тебе не сделать библиотеку для электрона которая покроет все известные кейсы и даст результат для всего electron сообщества?

По ряду причин: 1) Вырастут мои расходы на мейнтейнерство решения. Сейчас описанное мною решение реализовано в виде локального npm пакеты внутри монорепы основного приложения. Вынос его в публичный npm по-сути означает необходимость переноса в отдельный реп чтобы отдельно версионировать, тестить и релизить. Сейчас же я хочу сконцентрироваться на тасках моей прилки, чем на вклад в сообщество. 2) Мои npm пакеты не собираются в JS за ненадобностью: это делает Electron Forge перед упаковкой прилки. Для пубилкации в npm следует реализовать шаг сборки в JS. Это не звучит как работа, лежащая в моем роадмапе. 3) Все мои репы лежат на приватном self-hosted инстансе гитлаба. И мне придется либо открывать его для публичной сети с разруливанием доступа лишь к одному репу, либо лить это на клауд гитлаба/гитбах, что в моем рабочем флоу выглядит как пятая нога Поэтому увы, опенсурса не будет

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

* 1000 только на iOS приводит к крашу всего приложения

* 1000 только на iOS приводит к крашу всего приложения

Любопытно что в логах

пусто полностью было

У меня как то в аргументах у функции была пропущена запятая и при вызове её у меня крашился v8

Но это не электрон, просто нода, причём года 17-18

Привет, если кто то хочет в опенсорс, тому будет полезно сообщество единомышленников @OpenSource_Chat

А можно напомнить зачем знать? Ну если x86 пакет выполняется, значит это или х86 (i386) или х64 (amd64)

А можно напомнить зачем знать? Ну если x86 пакет выполняется, значит это или х86 (i386) или х64 (amd64)

1) Мне нужно формировать список JRE, которые можно запустить на машине юзера. Для этого мне нужно знать фактическую архитектуру оси. 2) x86 приложение может быть запущено и на arm64. Это и делает винда на arm