Dmitry Develop
رفتن به کانال در Telegram
Этот канал в основном будет интересен новичкам в программировании и людям немного поопытнее. Здесь я буду делиться своими новостями и достижениями в программировании. Разработка, программирование; c++, gcc, g++, gnu, mingw; winapi, windows; vscode.
نمایش بیشتر205
مشترکین
اطلاعاتی وجود ندارد24 ساعت
اطلاعاتی وجود ندارد7 روز
اطلاعاتی وجود ندارد30 روز
آرشیو پست ها
Запускаю из-под python дочерний процесс cmd.exe.
Хочу получать stdin и stderr в utf-8, так как не хочу определять или угадывать ANSI кодировку, поэтому в cmd.exe сначала выполняется chcp 65001, а потом всё остальное.
Но после чистого запуска появилась ошибка, типа не удаётся декодировать неправильный байт.
Начал разбираться и отлаживать, вручную запускать команду в терминале, и заметил, что chcp почему-то не влияет на терминал, запущенный через
cmd [/c|/k] (№1).
Если запускать его внутри другого терминала, поведение такое же, но после второго запуска всё становится правильным и почему-то изменяется кодировка родительского процесса (из-за наследования потоков?) (№2).
Почему происходит №1 и №2, что можно почитать, чтобы разобраться что и почему, можно ли это как-то решить?
Если просить вывод не в utf-8 из-за проблем windows с нет, то как тогда получать unicode вывод?
Нельзя же попросить вывод в utf-16?)
(Оказалось, вроде как только для .NET такое доступно)
>chcp
Текущая кодовая страница: 866
>cmd.exe /c "chcp 65001 > nul & testError"
"testError" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
>chcp
Active code page: 65001
>cmd.exe /c "chcp 65001 > nul & testError"
'testError' is not recognized as an internal or external command,
operable program or batch file.>chcp
Текущая кодовая страница: 866
>cmd.exe /c "chcp 65001 > nul & cmd /c "testError""
'testError' is not recognized as an internal or external command,
operable program or batch file.Если возникает исключение,
cpython вызывает функцию _Py_DumpPathConfig из python.dll и выводит "Python path configuration".
Значение program name там берётся из PyConfig *config = &tstate->interp->config; config->program_name.
Как из скрипта на python получить значение program_name или сразу PyConfig?
Есть sys.executable, но он даёт полный путь, а не название программы, которое было использовано при запуске.
Например, если запустить, "python", то config->program_name будет "python", а если "python.exe", то config->program_name будет "python.exe".
Вот пример запуска из cmd c выводом path configuration:
> python.exe
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = 'python.exe'
isolated = 0
environment = 0
user site = 1
import site = 1
sys._base_executable = 'path_to_python\\python.exe'
sys.base_prefix = 'path_to_python'
sys.base_exec_prefix = 'path_to_python'
sys.executable = 'path_to_python\\python.exe'
sys.prefix = 'path_to_python'
sys.exec_prefix = 'path_to_python'
sys.path = [
'path_to_python\\python38.zip',
'path_to_python\\DLLs',
'path_to_python\\lib',
'path_to_python',
'path_to_python\\lib\\site-packages',
]
> python
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = 'python'
isolated = 0
environment = 0
user site = 1
import site = 1
sys._base_executable = 'path_to_python\\python.exe'
sys.base_prefix = 'path_to_python'
sys.base_exec_prefix = 'path_to_python'
sys.executable = 'path_to_python\\python.exe'
sys.prefix = 'path_to_python'
sys.exec_prefix = 'path_to_python'
sys.path = [
'path_to_python\\python38.zip',
'path_to_python\\DLLs',
'path_to_python\\lib',
'path_to_python',
'path_to_python\\lib\\site-packages',
]
Python 3.8.20 (tags/3.8-dirty:39b2f82, Apr 9 2025, 03:36:20) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; print(sys.executable); print(sys.argv)
path_to_python\python.exe
['']
>>>Python path configuration" после запуска я экспортировал функцию _Py_DumpPathConfig и вызывал её перед Py_RunMain.
ссылка на канал | ссылка на группуСегодня целый день разбирался в исходном коде python.
Было очень сложно, ничего не понятно, откуда начать, куда смотреть, голова уже болит от объёма информации и от разных форматов данных.
Сборка сделана очень странно: где-то bat скрипты, где-то sh, makefile, sln, vcxproj...
Нет бы всё сделать через cmake.
Точка входа, то есть главные файлы, названы нелогично и непонятно.
Где-то это main.c, где-то python.c, WinMain.c, ...
Странная последовательность вызовов функций после точки входа:
[wWinMain, wmain, main] -> [Py_Main, Py_BytesMain] -> pymain_main -> Py_RunMain -> pymain_run_python ...
Но спустя много времени и при помощи метода тыка я нашёл все нужные мне точки интереса.
Но это уже потом, завтра буду с ними разбираться.
Сейчас у меня уже есть порядок вызова функций, вывод своих отладочных сообщений, я смог изменить как мне надо PyConfig и скомпилировать python.exe и python38.dll.
Дальше надо будет разобраться со статической компоновкой библиотеки и не только.
ссылка на канал | ссылка на группу
Сегодня хотел скомпилировать программу на C++ с минимальным размером исполняемого файла и без зависимостей от стандартной библиотеки, только winAPI, так как её суть всего лишь быть небольшой обёрткой для запуска другой программы.
Поискал нужные ключи для компилятора по своим проектам, запискам и в интернете, и нашёл их.
Но при компиляции с ними возникли странные ошибки.
Я уже успел забыть про них, и когда-то уже с ними сталкивался, но не сразу вспомнил, как их можно исправить.
Поиск в google похожей проблемы ничего не дал.
Не помню, было ли такое же поведение на более старых версиях gcc + mingw, но при сборке на gcc 14.2.0 и mingw 12.0.0 оно есть, и мне кажется, это баг или недоработка.
Хотя, возможно, так было и раньше, но я мог собирать код без
-ffreestanding, поэтому проблема себя не проявляла.
А если компилятор из-за оптимизаций или по другим причинам генерировал вызов любой функции из стандартной библиотеки или crt, то я просто получал ошибку компоновки.
Например, побайтовое копирование циклом for компилятор спокойно может оптимизировать в вызов функции memcpy.
Минимальный воспроизводимый пример состоит лишь из включения заголовочного файла windows.h и ключа компилятора -ffreestanding.
// g++ -ffreestanding -o winapi.exe winapi.cpp
#include <windows.h>
int main()
{
MessageBoxA(nullptr, "Hello world", "message", 0);
return 0;
};-ffreestanding макрос __STDC_HOSTED__ устанавливается в значение 0, поэтому hosted код исключается из сборки.
Беглым поиском я нашёл ещё несколько мест с такими же проверками, но почему-то их не оказалось в x86intrin.h, immintrin.h и xmmintrin.h (возможно, есть ещё такие), которые вне зависимости от значения __STDC_HOSTED__ используют функционал hosted окружения, который отсутствует в freestanding окружении.
Я не знаю для чего нужны эти заголовочные файлы и какое будет наиболее правильное решение, поэтому я сделал максимально простое и тупое решение.
Так как в этих заголовочных файлах вместо директивы препроцессора #pragma once используются header guards через #ifndef #def, я просто перед включением windows.h определил два нужных макроса, чтобы препроцессор не включал эти проблемные заголовочные файлы:
// g++ -ffreestanding -o winapi.exe winapi.cpp
#define _X86INTRIN_H_INCLUDED
#define _EMMINTRIN_H_INCLUDED
#include <windows.h>
int main()
{
MessageBoxA(nullptr, "Hello world", "message", 0);
return 0;
};-ffreestanding и получать ошибки на этапе компоновки, а второй это использовать ключ -ffreestanding и получать ошибки на этапе компиляции, но решать некоторые из них придётся костылями или редактированием заголовочных файлов стандартной библиотеки компилятора.
Вне зависимости от использованного способа, конкретно с этим MRE (Minimal Reproducible Example), размер исполняемого файла получается одинаковым.
Интересно даже, действительно ли это баг или недоработка.
Я не знаю, куда писать, но оставлять это как есть не хочется, поэтому буду рад ссылкам и советам, куда мне написать об этой проблеме.
ссылка на канал | ссылка на группуПродолжение предыдущей публикации.
Решил переписывать batch скрипт на python.
Язык мне этот нравится, некоторый опыт на нём я уже имею, интерпретатор весит мало, а сверхвысокая производительность не нужна.
Изначально я скачал только 32 битный python с расчётом на то, что такая разрядность будет универсальнее, так как сможет запускаться как на 32, так и на 64 битном оборудовании / установщике.
Но при запуске я получил ошибку, который в первый раз увидел:
"
Не удалось запустить приложение, поскольку его параллельная конфигурация неправильна".
("The application has failed to start because its side-by-side configuration is incorrect")
Прочитал информацию по этой ошибке и подумал, что дело в отсутствующих зависимостях.
В документации на python написано, что "The embedded distribution does not include the Microsoft C Runtime and it is the responsibility of the application installer to provide this", поэтому я подумал, что легко не будет.
Поэтому начал искать способ разрешить эти зависимости.
Скачал vc redist и искал способы как-то распаковать все нужные мне DLL библиотеки без их установки.
Открыть как архив в 7zip ничего полезного не дало.
Вспомнил про msiexec, но установочный файл формата exe.
В документации на vc redist нашёл аргумент командной строки layout, который "The /layout option copies the complete contents of the Redistributable in the current directory", но почему-то после запуска ничего не появилось ни в текущей рабочей папке, ни в папке temp.
Позже на форуме microsoft я нашёл тему с похожей проблемой.
В итоге при помощи google и какой-то древнего форума нашёл программу UniExtract2, которая умеет распаковывать различные форматы архивов и установщиков microsoft, и это помогло достать все нужные DLL.
Но прежде чем их подкидывать в папку python, я решил попробовать скачать ещё 64 битную версию и попробовать ещё раз.
И о чудо, в этот раз интерпретатор python смог запуститься в среде winPE и потом даже корректно выполнить скрипт!
Я, конечно, такого не ожидал.
Как мне казалось, это не какая-то простая программа, не самодостаточная, и не без внешних зависимостей.
Поэтому обязательно должно что-то пойти не так, ведь я использую программу в тех условиях, в которых разработчики, наверное, и не предполагали.
Но почему-то на 64 битном оборудовании и на такой же разрядности установщике 32 битная программа не запустилась.
Возможно, дело просто в отсутствии или по умолчанию выключенной подсистеме WoW64 в winPE.
В итоге распакованный vc redist не пригодился, но на всякий случай я его сохраню, да и опыт оказался очень интересным и полезным.
ссылка на канал | ссылка на группуМне нужно автоматизировать запуск некоторых программ с некоторыми аргументами в некоторой последовательности, с некоторой дополнительной логикой, с пользовательским вводом (выбором) в консольном интерфейсе.
Нужна возможность изменять реализацию прямо на месте, поэтому компилируемый язык для решения этой задачи не подойдёт, поэтому нужен скриптовый язык.
Скрипт будет лежать на флешке и потенциально запускаться на разных версиях операционной системы и её разрядности, в основном на windows.
У меня уже есть реализация на batch, но мне ужасно сильно не нравится его синтаксис, а так же привязанность к windows.
Примерно то же самое могу сказать про powershell и bash.
Что скажете насчёт написать скрипт на python?
Синтаксис этого языка мне нравится, и я уже когда-то на нём писал свою простую реализацию системы сборки, опыт приятный и положительный.
Но меня волнует требование носить с собой его portable интерпретатор.
Какие потенциальные могут проблемы быть с его запуском или работой скриптов?
Сможет ли portable сборка python запуститься в win PE во время установки windows?
ссылка на канал | ссылка на группу
What is the Strict Aliasing Rule and Why do we care?
(OR Type Punning, Undefined Behavior and Alignment, Oh My!)
https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8
Смотрел ещё недавно по этой теме трансляцию Ильи Мещерина и доклад на C++ Russia от Романа Русяева, поэтому чуть-чуть контекст, причины, цели и последствия понял.
Просто мозг взрывается от strict aliasing rule.
Очень, очень много правил, которые легко нарушить.
Единственные совместимые со всеми другими типами являются только
char, unsigned char, or std::byte.
Про signed char, int8_t и uint8_t в стандарте ни слова.
Не могу понять, почему нельзя перекрывать объект через signed char?
Да и знаковость char implementation defined, если не ошибаюсь, или просто не указана.
По идее, если для этого типа нет исключения, то будет undefined behavior.
Мне очень хотелось бы работать с байтами именно через типы-псевдонимы из stdint.h (cstdint), в которых, оказывается, нет псевдонима байта.
Хотя через минуту я вспомнил и понял, что: байт != 8 бит, поэтому на эту роль uint8_t не подойдёт.
Да и в статье упоминается, что эти псевдонимы могут, но не обязаны быть реализованы через char.
Ещё интересно, а можно ли как-то обойтись без placement new, std::launder, std::memcpy, чтобы не нарушить strict aliasing и реализовать, например, сериализацию и десериализацию?
Возможно, я просто заблуждаюсь и все проблемы от незнания, но я до сих пор воспринимаю те сущности просто, как часть стандартной библиотеки, как будто просто функцию, а не какое-то особенное ключевое слово, от которого никак не избавишься, не обойдёшься без, не переопределишь, не напишешь свою реализацию.
И ещё скорее всего из-за моего идеалистического взгляда на C++ и желаемый способ написания кода.
Where can I find what std::launder really does?
A byte type: std::byte vs std::uint8_t vs unsigned char vs char vs std::bitset<8>
ссылка на канал | ссылка на группуЗашёл сегодня в настройки роутера и случайно обратил внимание в разделе WAN на значение IP адрес, оно было вида
172.24.86.40.
Потом проверил IP, например, на сайте myip.com.
Там отображался отличный от WAN IP вида 83.224.86.40.
Стало интересно, а почему так.
Почитал различные форумы, инструкции и статьи от производителей сетевого оборудования.
Понял, всё сложно и интересно.
Решил узнать, к какой классификации и диапазону IP относятся те двое.
Первый это class B private (172.16.0.0-172.31.255.255), а второй это class A public (1.0.0.0-127.0.0.0).
То есть эти IP адреса имеют разную классификацию и попадают в разные диапазоны публичности.
У роутера для подключённых устройств есть своя локальная сеть, а из-за недостатка адресов ipv4 у провайдера (ISP) используется NAT (сетевая трансляция адресов), которая транслирует запросы от множества локальных адресов на один публичный в интернет и обратно транслирует ответ.
То есть между моим роутером и интернетом как минимум стоит ещё оборудование провайдера с настроенным NAT.
Ещё можно сделать вывод, что мой IP является серым, то есть на него нельзя напрямую делать запросы из интернета.
ссылка на канал | ссылка на группуВпервые за много лет я снова увидел VHS кассеты.
Сегодня её вручную ручкой крутил).
Нашёл дома старый VHS проигрыватель и кассету в нём, которую мне очень нравилось в детстве пересматривать.
В процессе перемотки кассеты я услышал громкий шелест ленты.
Мне показалось это странным, и я сразу прервал процесс перемотки и извлёк кассету.
Оказалось, магнитная лента вылезла и перекрутилась.
Пришлось гуглить, как снять стопор в кассете, выровнял, распутал и заправил ленту обратно.
ссылка на канал | ссылка на группу
Есть обновление по этой публикации, где я предлагал использовать параметр "
terminal.integrated.profiles.windows" для изменения значения системной переменной path по умолчанию у встроенного терминала и при запуске задач.
Изначально, я искал это решение именно для той цели, но потом подумал для примера добавить выполнение команд некоторых действий при запуске.
В той публикации видно, что всё работает, текст выводится, префикс ввода меняется.
Однако, на этом плюсы заканчиваются.
Когда я попробовал запустить задачу типа shell, они оказались сломанными.
С чего бы тут начать объяснение...
Ну, начну с того, что тут есть две причастные стороны.
Почему-то cmd не поддерживает выполнение нескольких команд, разделённых аргументами командной строки.
У cmd довольно большой список аргументов, поэтому я покажу сокращённый пример синтаксиса и ключей, которые я использовал, полный список вы можете сами посмотреть в документации.
cmd [/c|/k] [/d] [<string>][<string>], а если запускать несколько cmd подряд, то это не будет иметь нужного эффекта, так как они не будут наследовать переменные среды друг друга, так как являются независимыми процессами.
При запуске задач типа shell vs code использует полный путь до исполняемого файла терминала или его оболочки и какие-то аргументы по умолчанию, после этого он добавляет command и args из описания задачи.
И при изменении args для профиля терминала через параметр "terminal.integrated.profiles.windows", vs code почему-то просто конкатенирует новые аргументы с аргументами по умолчанию, хотя такое поведение кажется нелогичным.
Например, так выглядит команда по умолчанию при запуске shell задачи с command "echo" c args "world" :
C:\windows\System32\cmd.exe /d /c echo world"terminal.integrated.profiles.windows":
{
"Command Prompt":
{
"path":
[
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe",
],
"args":
[
// "/k",
"/c",
"echo",
"hello",
],
"icon": "terminal-cmd",
},
},C:\windows\System32\cmd.exe /k /c echo hello /d /c echo worldcmd [/c|/k] [/d] [<string>] [/c|/k] [/d] [<string>]..." или vs code при переопределении настроек профиля терминала добавлял только command и args из задачи без конкатенации аргументов терминала по умолчанию, то это бы работало, но увы.
Поэтому я не рекомендую использовать предложенный мной способ для cmd.exe.
Если вы используете другие терминалы или их оболочки, посмотрите shell integration в документации vs code.
А если вам нужно только добавить или изменить переменные среды, то я нашёл настройку "terminal.integrated.env.windows", которая работает просто идеально: влияет как на встроенный терминал, так и на задачи вида shell и process, и не ломает их:
"terminal.integrated.env.windows":
{
"path": "C:\\HELLO;${env:path}",
},terminal.integrated.env.windows" можно объединить с пользовательскими настройками, и получится что-то такое:
"mySettings.compilerPath": "C:\\compiler\\bin",
"mySettings.gitPath": "C:\\git\\bin",
"mySettings.pythonPath": "C:\\python\\bin",
"mySettings.customPath": "${config:mySettings.compilerPath};${config:mySettings.gitPath};${config:mySettings.pythonPath};${env:path}",
"terminal.integrated.env.windows":
{
"path": "${config:mySettings.customPath}",
},1 часть
2 часть
Для проверки, как мне кажется, бага, вы можете скопировать себе эти задачи и запустить их:
{
"version": "2.0.0",
"tasks":
[
// bug task process
{
"label": "bug task process",
"type": "process",
"command": "cmd.exe",
// "command": "${env:windir}\\System32\\cmd.exe",
"args":
[
"/c",
"echo",
"%path%"
],
"group": "build",
// "options":
// {
// "env":
// {
// "path": "C:\\HELLO;${env:path}",
// },
// }
},
// bug task shell
{
"label": "bug task shell",
"type": "shell",
"command": "echo",
"args":
[
"%path%"
],
"group": "build",
// "options":
// {
// "env":
// {
// "path": "C:\\HELLO;${env:path}",
// },
// }
},
],
// "options":
// {
// "env":
// {
// "path": "C:\\HELLO;${env:path}",
// },
// }
}options.env.path, если хотите закомментировать только значения в env параметре.
Чтобы исключить влияние кеширования значения path, которое может повлиять на результаты запуска будущих задач, после каждого запуска задачи, я принудительно убивал процесс терминала.
Сначала попробуйте запустить обе задачи без каких-либо изменений:
Обе задачи успешно запустятся и выведут вам ваше системное или пользовательское значение переменной среды path.
Пример вывода shell задачи:
* Executing task in folder project: echo %path%
C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
* Terminal will be reused by tasks, press any key to close it.* Executing task in folder project: C:\windows\System32\cmd.exe /c echo %path%
C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
* Terminal will be reused by tasks, press any key to close it. options.env.path глобально или локально, shell типы задач будут успешно запускаться и выводить переопределённое значение path:
* Executing task in folder project: echo %path%
C:\HELLO;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
* Terminal will be reused by tasks, press any key to close it. Executing task in folder project: C:\Users\user\storage\development\project\cmd.exe /c echo %path%
The terminal process failed to launch: Path to shell executable "C:\Users\user\storage\development\project\cmd.exe" does not exist.cmd.exe" указать "${env:windir}\\System32\\cmd.exe", process задачи тоже будут работать:
* Executing task in folder project: C:\windows\System32\cmd.exe /c echo %path%
C:\HELLO;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
* Terminal will be reused by tasks, press any key to close it.1 часть
2 часть
Продолжаю искать различные способы передать изменённую переменную среды path при открытии встроенного терминала и при запуске задачи, а так же провожу эксперименты.
Решил пока остановиться на поиске способа для
tasks.json, так как с настройкой на уровне settings.json всё оказалось просто и понятно, она прекрасно работает, как и задумано, а вот для задач всё странно.
Я нашёл параметр options.env.path, но в процессе экспериментов и тестирования различных комбинаций настроек, я заметил неожиданное и непонятное, неправильное поведение.
Если определить этот параметр глобально на уровне tasks или локально на уровне уровне отдельной задачи и изменять там переменную среды path, то задачи типа process почему-то перестают находить стандартные системные исполняемые файлы, например, cmd.exe.
Такое чувство, что ломается или затирается path для самого vs code.
Но я такого ещё не видел, чтобы настройки в vs code могли менять его собственные переменные окружения, или чтобы задача сразу использовала изменённые переменные окружения для запуска процесса, дочерний процесс может их только наследовать или получать переопределённую версию.
Таким образом никакие мои настройки не должны приводить к тому, чтобы vs code не мог найти при запуске process задачи cmd.exe, так что я думаю, что я нашёл баг.
Нигде в документации я не нашёл каких-то предостережений или правил, которые запрещали бы мне изменять path для дочернего процесса, и что это бы сломало запуск задач.
При этом, если указать полный путь до cmd.exe, то задача успешно запускается и процесс получает правильный изменённый path.
Ещё я заметил, как мне кажется, странное поведение при определении настройки options.env.path как глобально, так и локально.
Если в глобальной настройке переопределить path, а в локальной оставить пустой список:
// глобально
"options":
{
// изменение только переменной path
"env":
{
"path": "C:\\HELLO;${env:path}",
},
}
// локально
"options":
{
// пустой список, ничего не добавляется, не изменяется и не удаляется
"env":
{
},
}Совершенно случайно при редактировании файла вместо ctrl + C нажал ctrl + shift + C, и внезапно у меня открылась отдельная от vs code обычная cmd консоль.
Подумал, что-то тут не так, в смысле..., откуда появилась консоль, если я просто копировал текст?
Решил проверить текущие горячие клавиши / назначения клавиш.
Оказывается, в vs code есть (или появилось) назначение клавиш по умолчанию ctrl + shift + C на открытие внешнего терминала.
Интересно, а меняет ли vs code этому новому процессу консоли переменные среды PATH, если из как-то менять или дополнять через настройки?
Хороший вопрос, который надо будет проверить.
(Оказалось, нет, только cwd меняет)
Обычно, я стараюсь какие-то незначительные вещи не выкладывать в виде публикации в канале, а просто кидаю в группу.
Но последние три дня я 24/7 мучаюсь с vs code и, кажется, у меня есть интересные результаты и выводы, а также, возможно, я случайно нашёл один баг).
Перед написанием огромной публикации, что, на самом деле, является очень большим и трудоёмким процессом, особенно в моём-то стиле написания, хочется сделать какие-то простые публикации, не напрягаться сильно, и чтобы канал не пустовал.
Да и такая информация может быть кому-то полезна).
(И никто не сказал, что "трудоёмкий труд" это речевая ошибка, тавтология)
ссылка на канал | ссылка на группу
Немного полезной информации).
Мне всегда было интересно, где взять оригиналы стандартных фонов рабочего стола windows.
Тем более мне сейчас не понравилось в windows 11 то, что на рабочем столе стоит полная версия фона, а на экране блокировки какая-то урезанная, а каких-то параметров заполнения я не нашёл, поэтому решил установить принудительно нужный фон.
Осталось только найти, где хранятся оригинальные фоны в системе.
Немного погуглил и нашёл:
В windows 10 и 11 стандартные фоны хранятся в папке "тёмной чёрной темы, я сделал чёрно-белый вариант тех фонов:
img0Blacked.jpg и img19Blacked.jpg
ссылка на канал | ссылка на группу
C:\Windows\Web".
Обычно, в этой папке есть ещё подпапки для каждой из тем (например, Flowers, Windows) и разрешений экрана (например, 4K).
Теперь фон блокировки выглядит точно так же, как и фон рабочего стола.
Если кому-то будет интересен фон для светлой и тёмной темы в разрешении 4K, я их приложил к этой публикации.
Для любителей особо ⚠️ не используйте этот способ, пока не прочитаете обновление по этой публикации:
https://t.me/a248640develop/330
Продолжаю настраивать чистый и пустой vs code после переустановки windows 11.
Следующая проблема, с которой я столкнулся, оказалась в отсутствии папки bin компилятора в переменных среды (PATH), из-за этого не запускается скомпилированная им программа, так как она не полностью самодостаточна и зависит его его библиотек времени выполнения (runtime).
Странно, что я до сих пор не сделал публикацию в канале на тему "portable/standalone/переносных программ", так как я думал не неё сослаться или сделать отсылку.
Но в своей группе я неоднократно говорил насколько сильно мне нравится такой вид программ и наличие возможности выбора.
Проблема понятна, просто добавить папку в переменные среды и всё, но я, как любитель переносных программ и по возможности минимального вмешательства в систему подумал, а можно ли как-то обойтись без изменения PATH, чтобы программа работала?
Я знаю, что в терминале можно временно изменять переменные окружения.
Например, для cmd будет:
set path=path_to_compiler_bin;%path%.
Это самый простой способ временно изменить PATH и запустить процесс с этими изменёнными переменными, и чтобы windows смогла найти все нужные exe и dll файлы.
Я подумал, а можно ли как-то в vs code перед запуском терминала выполнить какую-то свою команду или запустить скрипт?
Как активация виртуального окружения python, например.
Да, можно, для этого есть настройка "terminal.integrated.shellArgs.windows": [""], но она, к сожалению или к счастью, стала устаревшей и была удалена.
На замену ей пришли профили терминала: "terminal.integrated.profiles.NNN", в которых можно не только создавать свои, но и переопределять настройки для стандартных, можно поменять не только аргументы, которые мне были и нужны, но и путь до исполняемого файла и даже иконку.
В настройки уровня пользователя, проекта или решения нужно добавить следующий текст:
// settings.json
{
"terminal.integrated.profiles.windows":
{
"Command Prompt":
{
"path":
[
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe",
],
"args":
[
"/k",
"echo hello & echo world & prompt $g$s",
],
"icon": "terminal-cmd",
},
},
"terminal.integrated.defaultProfile.windows": "Command Prompt",
}Microsoft Windows [Version 10.0.22631.4602]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.
C:\Users\user>_hello
world
> _echo hello & echo world & prompt $g$s" можно сделать вызов любого скрипта, даже vcvarsall.bat, что позволит легко использовать компилятор cl.exe (MSVC).
ссылка на канал | ссылка на группу