да нет, дело не в шифровании:
int main(int argc, wchar_t* argv[]) ... printf("%s ", argv[i]);
%s -- это не тот формат, который можно использовать для вывода строки wchar_t*. Этот код частично работает потому что ты не работаешь с отдельными символами argv, если бы ты стал это делать, ты бы сразу увидел, что что-то сильно не так. Попробуй в этой программе посимвольно напечатать аргументы.
читал в одном источнике, что на Windows новых версий наоборот аргументы в cmd.exe передаются в Unicode
я реализовал чтение аргументов через функции WinAPI, заключив их в #ifdef. Насколько это индусский код, и что с ним будет на Linux?
в чём отличие преобразования (wchar_t*) в (char*) явным образом и вызова wcstombs?
после расшифровки строки с русскими буквами и её вывода на консоль получался мусор. Это так и должно быть, или где-то в моём коде есть баг, который к этому приводит?
Вопрос в том, что может я где-то усложнил себе жизнь?
Я говорил о том, что после прохода отладчиком в папке остаётся exe файл.
Например так. Да, ламерский подход
strcat не меняет размер выделенной для строки памяти, это нужно делать самостоятельно перед её вызовом.
видимо, то, что я вижу в режиме отладки - это работа некого интерпретатора, исполняющего мой код построчно, я прав?
у меня собирается
all:$(CPP_EXECUTABLE)
CPP_EXECUTABLE :=$(CPP_SOURCES:.cpp=)
CPP_SOURCES :=$(wildcard *.cpp)*.cpp, я очень хотел бы узнать, как оно у тебя собирается.itoa, но это нестандартная функция, в стандартную библиотеку C она не входит.
Это что за проблемы могут быть, что нужно лезть настолько вниз?
насколько реально отследить такой баг в ассембли? И почему без его знания не поймёшь, что это баг?
Maksim Ivanov, ты зря упираешься, но дело, конечно, твоё.