none7

Так и должно быть. Если Вы хотите прочитать весь файл в строку, то смотрите пример.

textBox4->Text = System::Convert::ToString(chislo);// тут какой из этих методов должен по Вашему вызываться? Странно, что оно вообще компилируется.

post += "Content-Length: " + to_string(post.length()) + "\r\n";
Здесь должно быть число байт отправляемых после \r\n\r\n(теле запроса), а не длина хидеров до этой строчки кода. Что должно быть в теле запроса зависит, от того, что именно Вы пытаетесь сообщить серверам телеграмма. В вашем случае длина тела 0 байт.

int *p = (int*)0x0046FCF0;
Только вот в нынешних ОС обычно не бывает никаких фиксированных адресов. Такое может быть нужно, разве, что при программировании микроконтроллеров или драйверов под ARM.

Стек(хранилище локальных переменных и адресов возврата из функций) смещается сверху вниз(stack -= sizeof(struct allvalrs) / sizeof(void*)). То есть при запуске нового потока, его указатель стека находится на вершине. Соответственно Ваш код размещает переменные чуть ниже вершины и любой значительный плюс приводит указатель в не выделенную область памяти.

Неправильное Вы выбрали решение проблемы.

InternetReadFile(hRequest, strContent, sizeof(strContent)/* - 1*/, &dwByteRead);
return string(strContent, dwByteRead);

InternetReadFile это не строковая функция, она не добавляет ноль в конец массива и более того, может добавить их в любое место массива, если читается двоичный файл. Есть к слову такой класс уязвимостей, когда строка то массив символов вроде std::string, то null-terminated. Проверки одного совершенно ничего не значат, для другого, так как std::string может хранить нулевой символ!

Я конечно понимаю, что лень, но всегда нужно писать обработку ошибок, тогда было бы очевидно где проблема. У меня есть 2 варианта почему может не работать:
1. Разрядность Вашего приложения не та же, что и у атакуемого процесса.
2. Расположение kernel32 в атакуемом процессе отличается от расположения в Вашем.

Изначально операция *указатель пришла из Си и там она называлась "разыменования указателя". Означает, что все операции будут произведены со значением на которое ссылается указатель. При присвоении значения другой переменной будет создана копия значения. Но в C++ всё осложнило введение ссылочного типа, символ '&'. Это тот же указатель, но каждая операция с ним аналогична *(указатель) и соответственно арифметика указателей со ссылками невозможна(без приведения типов).
В данном примере происходит разыменование указателя на объект, но так как возвращаемый тип ссылка, то происходит автоматическое приведение типа в неё. Логично предположить, что в результате операции += произойдёт копирование из ссылки, но ничерта, она просто выбрасывается...

CreateProcess всё равно какое расширение у исполняемого файла, если оно не в списке расширений исполняемых файлов. Так, что можно переименовать любой .exe в load.txt и запустить функцией CreateProcess.

Если права админа требуются всегда, то см. Setting the Execution Level in the Application Manifest. Иначе запуск программы через ShellExecute("runas") и передача дочернему процессу необходимых данных.

Ваша программа, это не sh скрипт. И пара строк:

std::system("export myvar=1");
std::system("echo $myvar");

неожиданно выведут пустую строку. Нужно либо устанавливать переменную в том же вызове system(env LD_LIBRARY_PATH=${LD_LIBRARY_PATH} path/to/app) или ручками менять переменные своей программы(getenv/setenv).

for (int i = 0; i < 6; ++i) {
      rNum = rand() % sizeof(alphanum);
      file << alphanum[rNum];
}

У тебя тебя sizeof(Login::password) == 90, так откуда взялось 6? Кто будет дописывать остальные 84 байта? Кстати sizeof(alphanum) больше на 1 чем ты ожидаешь потому, что в Си все строки оканчиваются символом '\0'. Поэтому есть вероятность, что alphanum[rNum] == '\0'.

P.S. Если файл "login.data" уже существует к моменту readfile.open() и он больше чем нужно, то его размер останется прежним. А на хвосте файла будет чёрт знает что, мусор.

Операторы >> и << очень капризны. И char[300] они распознают как char*. Может случиться переполнение буфера если символов больше 300 и чтение или запись будет остановлено если встретится символ пробела, конца строки или \0. Соответственно при записи пишется не 300 байт, а до разделителя. При чтении никаких разделителей не встретится так, что всё будет прочитано всё в первую структуру и может произойти переполнение буфера. Используйте istream::getline(void), istream::read(char* buf, streamsize n), ostream::write(const char* buf, streamsize n);
Вообще лучше не смешивать Си и С++, по всюду будут вылазить те или иные баги. Вместо char[300] std::string, вместо массивов std::array или std::vector. От фиксированной длины тоже желательно избавиться и сириализовать данные скажем в .csv

Дело не в коде, дело в компиляторе MS. Если Вы преобразуете кодировку документа в UTF-8 без BOM, то код будет(вероятно) работать как и должен. "Вероятно" потому, что даже без BOM он может догадаться, что документ в UTF-8. И тогда компилятор непременно преобразует все char[] строки из UTF-8 в системную ANSI кодировку.

Приватный или нет, это важно лишь на уровне проверки исходного кода. Оптимизатор же должен только выдать код, результат которого во время выполнения будет идентичен ожидаемому. Есть ли смысл? Gcc сам сделает inline столь короткого метода во время компиляции, если увидит его реализацию, но полагаю может возникнуть конфликт во время линковки, если один и тот же метод без inline будет подключаться к нескольким файлам. MSVC сам оптимизирует этот участок во время линковки даже если компилятор не видел реализации соответствующего метода.

С машинной точки зрения нет особой разницы между bool,char и int, просто первые 2 в памяти обычно занимают меньше места. Также операции -x и x^255 выполняются одинаково быстро, то есть тоже никакой разницы.