- fix(8.82): вставка из буфера обмена для F5 .xxxx считалась невалидной - fix: кривой дамп для двухбайтовых кодовых страниц - калькулятор: #[bwdq] как big-endian
Поддерживаю вопрос. Может попробовать перекомпилировать с winelib, чтоб представить насколько это будет сложно? Тут нашёл примерный гайд, не знаю насколько поможет: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User%27s-Guide
А с юникодом в именах файлов как не работала программа, так и не работает. Сложно что ли проверить наличие "???" в имени файла и работать с ним по короткому имени?
Не стоит так дерзить незнакомым людям, тем более замечание было по делу. Вот пример с исходником и пара файлов для тестов, один из которых с "некорректным" именем. https://www.upload.ee/files/17753366/unicode.zip.html Надеюсь, с переводом Ассемблера на С проблем не возникнет.
командная строка в хиеве немного сложнее одного имени, Ф9 тоже этот пример не трогает. и что будет делать GetShortPathNameW на системе, где 8+3 отключены ?
Это был всего лишь пример, как можно без проблем обработать юникодное имя файла в ком.строке ascii-приложения. Я также не вижу никаких сложностей, чтобы обрабатывать и другие параметры.
>> Ф9 тоже этот пример не трогает
Неужели надо было еще добавлять примеры с FindFirstFileW \ FindNextFileW ? Проверки и преобразования имен файлов будут точно такие же. В результате в списке будут длинные имена файлов, которые соответствуют кодировке ascii, плюс короткие имена файлов для юникода.
>> что будет делать GetShortPathNameW на системе, где 8+3 отключены ?
За десятилетия админства и кодерства ни разу не встречал таких систем. В этом случае функция просто вернет длинное имя, которое не будет открываться или будет криво отображаться, как это происходит сейчас. Но это уже будет исключение и личная проблема маленькой горстки самих-себе-злобных пользователей, которые что-то накрутили у себя в системе.
главная проблема примера в том что множество юникодовских имен переводится в анси безо всяких ? вопрос с некорректным переводом решается только переписыванием всех файловых операций на apiW.
> За десятилетия админства и кодерства ни разу не встречал таких систем.
Уж кто-то, а админы просто обязаны встречать такие системы. Потому что на больших файловых серверах часто отключают 8+3 по соображениям производительности.
Hiew как бы и компании юзают. У которых может быть файловый сервер с отключенным 8+3. И пользователь запросто может открыть в Hiew файл, расположенный на сетевом диске такого файлового сервера.
Мир не без добрых людей, видимо не я один это всё читаю. Руборду спасибо, хотел сам что-то подобное сделать, но и без меня в Красной Армии штыки нашлись. Серверы, 8:3, отключения, это все оставьте на hiew 10.0. На этом мою часть дискуссии оставлю.
>главная проблема примера в том что множество юникодовских имен переводится в анси безо всяких ? Евгений, ну WideCharToMultiByte же с флажком WC_NO_BEST_FIT_CHARS? Или мы сейчас не об этом?
Добрый день. Рассчитываете перенести hiew под linux?
ОтветитьУдалитьдаже не планирую
УдалитьПоддерживаю вопрос. Может попробовать перекомпилировать с winelib, чтоб представить насколько это будет сложно? Тут нашёл примерный гайд, не знаю насколько поможет: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User%27s-Guide
ОтветитьУдалитьА с юникодом в именах файлов как не работала программа, так и не работает. Сложно что ли проверить наличие "???" в имени файла и работать с ним по короткому имени?
ОтветитьУдалитьну раз ты такой умный, расскажи как получить короткое имя из некорректного ?
УдалитьНе стоит так дерзить незнакомым людям, тем более замечание было по делу. Вот пример с исходником и пара файлов для тестов, один из которых с "некорректным" именем. https://www.upload.ee/files/17753366/unicode.zip.html
УдалитьНадеюсь, с переводом Ассемблера на С проблем не возникнет.
есть разница между незнакомыми и анонимными.
Удалитькомандная строка в хиеве немного сложнее одного имени, Ф9 тоже этот пример не трогает.
Удалитьи что будет делать GetShortPathNameW на системе, где 8+3 отключены ?
Это был всего лишь пример, как можно без проблем обработать юникодное имя файла в ком.строке ascii-приложения. Я также не вижу никаких сложностей, чтобы обрабатывать и другие параметры.
Удалить>> Ф9 тоже этот пример не трогает
Неужели надо было еще добавлять примеры с FindFirstFileW \ FindNextFileW ? Проверки и преобразования имен файлов будут точно такие же. В результате в списке будут длинные имена файлов, которые соответствуют кодировке ascii, плюс короткие имена файлов для юникода.
>> что будет делать GetShortPathNameW на системе, где 8+3 отключены ?
За десятилетия админства и кодерства ни разу не встречал таких систем. В этом случае функция просто вернет длинное имя, которое не будет открываться или будет криво отображаться, как это происходит сейчас. Но это уже будет исключение и личная проблема маленькой горстки самих-себе-злобных пользователей, которые что-то накрутили у себя в системе.
главная проблема примера в том что множество юникодовских имен переводится в анси безо всяких ?
Удалитьвопрос с некорректным переводом решается только переписыванием всех файловых операций на apiW.
> За десятилетия админства и кодерства ни разу не встречал таких систем.
УдалитьУж кто-то, а админы просто обязаны встречать такие системы. Потому что на больших файловых серверах часто отключают 8+3 по соображениям производительности.
>Потому что на больших файловых серверах часто отключают 8+3 по соображениям производительности.
УдалитьHiew серверное приложение? :)
> Hiew серверное приложение? :)
УдалитьHiew как бы и компании юзают. У которых может быть файловый сервер с отключенным 8+3. И пользователь запросто может открыть в Hiew файл, расположенный на сетевом диске такого файлового сервера.
Мир не без добрых людей, видимо не я один это всё читаю. Руборду спасибо, хотел сам что-то подобное сделать, но и без меня в Красной Армии штыки нашлись. Серверы, 8:3, отключения, это все оставьте на hiew 10.0. На этом мою часть дискуссии оставлю.
Удалить>главная проблема примера в том что множество юникодовских имен переводится в анси безо всяких ?
УдалитьЕвгений, ну WideCharToMultiByte же с флажком WC_NO_BEST_FIT_CHARS? Или мы сейчас не об этом?
и куда этот WC_NO_BEST_FIT_CHARS ?
Удалитьимя файла УЖЕ ПЕРЕВЕДЕНО из юникода в анси.
Zeroes
Удалитьсерверное - несерверное, а под телнетом работает. по крайней мере раньше точно работало.
Доброго времени суток! Есть ли в HIEW в. 8.83 поддержка дизассемблера для кода CPU AArch64?
ОтветитьУдалитьбудет после оплаты всеми желающими
Удалить