Комментарии 82
Удалить приложение PowerShell, заменив его Windows PowerShell;
Что такое PowerShell, и чем он отличается от Windows PowerShell?
Допустил неопределеннось, виноват.
PowerShell — новая мажорная версия (в моем случае 7-ка, 7.1.2), на которую предлагает перейти Windows PowerShell, устанавливаемая по умолчанию (у меня 5.1).
PowerShell — кроссплатформенная (кроссплатформенность, вероятно, начинается с 6-ки). Но вот функциональность пока не очень. Собственно, корректнее будет не «удалить», а «не устанавливать PowerShell». Спасибо за замечание, поправлю.
PowerShell — новая мажорная версия (в моем случае 7-ка, 7.1.2), на которую предлагает перейти Windows PowerShell, устанавливаемая по умолчанию (у меня 5.1).
PowerShell — кроссплатформенная (кроссплатформенность, вероятно, начинается с 6-ки). Но вот функциональность пока не очень. Собственно, корректнее будет не «удалить», а «не устанавливать PowerShell». Спасибо за замечание, поправлю.
Вы про PowerShell Core?
Скорее нет, чем да.
Я вот про что:
PS C:\Users\ova45> $PSversiontable
Name Value
— — PSVersion 7.1.2
PSEdition Core
GitCommitId 7.1.2
OS Microsoft Windows 10.0.19041
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Это уже кроссплатформенная, а не дефолтная
Я вот про что:
PS C:\Users\ova45> $PSversiontable
Name Value
— — PSVersion 7.1.2
PSEdition Core
GitCommitId 7.1.2
OS Microsoft Windows 10.0.19041
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Это уже кроссплатформенная, а не дефолтная
Скорее нет, чем да.
А вот это что?
PSEdition Core
А… ок. Значит про нее.
PS Core поддерживает Unicode, по крайней мере, по всей документации. Я не могу сейчас развернуть экземпляр и проверить, но подозреваю, что у вас в тестах где-то ошибка.
Вы, например, на чистой системе без настроек и без CHCP пробовали?
Не, я не сомневаюсь в поддержке Юникода со стороны PS Core. Иначе и быть не может.
Думаю, проблема в другом, и суть ее вы уловили — «на чистой системе без настроек и без CHCP». PS Core как-то по-другому интерпретирует команды Windows. Конкретно — СHCP.
Думаю, проблема в другом, и суть ее вы уловили — «на чистой системе без настроек и без CHCP». PS Core как-то по-другому интерпретирует команды Windows. Конкретно — СHCP.
Не, я не сомневаюсь в поддержке Юникода со стороны PS Core. Иначе и быть не может.
Тогда зачем рекомендация "Про PowerShell забываем раз и навсегда."?
Не навсегда, а до следующей мажорной версии.
Навсегда — это эксцесс исполнителя.
Все равно зачем?
Вот смотрите. Вы мне не ответили на неявно поставленный вопрос — как с помощью CHCP изменить кодовую страницу вывода. Моя версия насчет формата с двумя страницами тоже не подтвердилась. А значит, по моему мнению, CHCP в данной версии работает некорректно.
Вы мне не ответили на неявно поставленный вопрос — как с помощью CHCP изменить кодовую страницу вывода.
Не знаю.
А значит, по моему мнению, CHCP в данной версии работает некорректно.
Ну если ваша задача — это CHCP вызвать, то да, вам не подойдет.
С чего бы это? Моя задача, конкретно здесь и конкретно на первом этапе, была предельно проста — показать как установить дефолтную кодовую страницу в реестре. Она устанавливается с помощью команды CHCP. CHCP в PS Core работает некорректно. Возможно, в PS Core есть масса других полезных функций. Да та же кроссплатформенность.
Но тема поста — не PS Core.
Но тема поста — не PS Core.
Добавлю. Если привычная функция, любая, в новой версии начинает вести себя некорректно, значительно снижая свою функциональность, имхо, это вполне достаточное основание полагать, что новая версия не доработана.
… или что эта функция, вообще-то, не является частью новой версии, и поэтому вы можете ждать своей "доработки" бесконечно.
вообще-то если «эта функция не является частью новой версии», то она не явялется частью новой версии. Неожиданно, правда?
Другое дело, что часто «эта функция» сохраняется для совместимости со старой версией, а к ней добавляется аналогичная новая с расширенным фнкционалом. Примерно так же, как это и произошло с PS и PS Core.
Другое дело, что часто «эта функция» сохраняется для совместимости со старой версией, а к ней добавляется аналогичная новая с расширенным фнкционалом. Примерно так же, как это и произошло с PS и PS Core.
Вот теперь проблема стала понятнее, но от этого не перестала быть проблемой. В отличие от предыдущих версий, PS Core по команде CHCP устанавливает не обе кодовых страницы, а только страницу ввода.
Возможно, у нее существует формат (не проверял) типа
CHCP inputpagenum outputpagenum
Возможно, у нее существует формат (не проверял) типа
CHCP inputpagenum outputpagenum
Изменить кодовую страницу консоли Windows по умолчанию на UTF-8 (qastack.ru)
Вот корректная ссылка. Не надо пользоваться мусорными промптопереводилками.
superuser.com/questions/269818/change-default-code-page-of-windows-console-to-utf-8
Спасибо за ссылку. Честно говоря, я не придал ей большого значения, потому что те, кого подробности действительно интересуют, по этой же ссылке (а она все-таки, как и пост, русскоязычная), или с ее помощью уйдут на оригинал. Ну а кроме того, как мне кажется, в контексте данного поста подробности не столь важны, поскольку основная идея — русифицируйте консоль в коде, и будет вам счастье.
Однако в общем смысле вы, конечно, правы. Ваше замечание учту.
Однако в общем смысле вы, конечно, правы. Ваше замечание учту.
Для смены кодировки есть такие свойства консоли, можно не импортировать функции:
Console.OutputEncoding = System.Text.Encoding.UTF8;
Console.ItputEncoding = System.Text.Encoding.UTF8;Верно, спасибо за замечание. По существу об этом нужно было упомянуть, но тогда нужно упомянуть и о том, что эти функции ограничены кодировками Юникода, плюс дефолтная кодировка Net, плюс 7-битная ASCII. На этом все. Более полезны были бы свойства типа Console.OutputEncoding.CodePage, но к сожалению, они ReadOnly.
С другой стороны, в контексте данного поста, упомянутых вами функций вполне достаточно — мы же стремимся к Юникоду, верно? Так что спасибо, поставил бы плюсик за коммент, но карма не позволяет.
С другой стороны, в контексте данного поста, упомянутых вами функций вполне достаточно — мы же стремимся к Юникоду, верно? Так что спасибо, поставил бы плюсик за коммент, но карма не позволяет.
оболочки PowerShell (PS), Windows PowerShell (WPS) и Terminal
«Windows Terminal» — представитель отдельного класса приложений
Windows Terminal, ConEmu, Hyper — это эмуляторы терминалов или консолей
PowerShell, bash, cmd — это оболочки, shell, cli (command-line interpreters)
What's the difference between a console, a terminal, and a shell?
Ну знаете, это все споры о терминах. По существу все вышеперечисленное — это оболочки или обертки. Интерпретаторы команд Windows API. Microsoft называет это все командным процессором. Из чего это следует? А вот из чего — параметры раздела реестра \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor влияют на все перечисленные оболочки. Почит все параметры на почти все оболочки.
Microsoft называет это все командным процессором
Можно, пожалуйста, ссылку на то место, где Microsoft называет Windows Terminal командным процессором?
Предлагаю о терминах не спорить. Если хотите, можете называть Terminal оболочкой над оболочками.
Все «эмуляторы», «консоли» и пр. работают под управлением вот этой строки реестра Windows: \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor.
Переведено с английского языка.-Терминал Windows — это интерфейс командной строки с несколькими вкладками, который Microsoft разработала для Windows 10 в качестве замены консоли Windows. Он может запускать любое приложение командной строки, включая все эмуляторы терминала Windows, на отдельной вкладке. Википедия (Английский язык)
Все «эмуляторы», «консоли» и пр. работают под управлением вот этой строки реестра Windows: \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor.
НЛО прилетело и опубликовало эту надпись здесь
Стратегия локализации приложения в консоли
Вообще же, я пребывал в уверенности, что "гарантированная локализация" — это когда вы отдаете программу пользователю, а оно у него работает так, как вам бы хотелось. И если пользователю для этого надо выкинуть используемый им шелл и поставить другой — это как-то очень странно.
Верно. Поэтому пост нацелен на программную локализацию консоли, а выкинуть/добавить шелл — это как бы предварительные, но не очень удачные действия. Жаль, что акцент не удался.
Поэтому пост нацелен на программную локализацию консоли, а выкинуть/добавить шелл — это как бы предварительные, но не очень удачные действия.
Это вредные действия.
Я бы не был столь категоричен. Возможно, учитывая общий контекст, излишние действия. Однако не следует забывать, что можно элементарно забыть о добавлении установки кодовой страницы в код. А в результате этих вредных действий, с большой долей вероятности вы таки получите локализованную консоль.
Ровно наоборот. В результате этих действий я, как разработчик, получу локализованный вывод, не заметив, что среднестатистический пользователь его не получит. Это и есть вред.
Я вашу логику уловил сразу, пояснения излишни. Я исхожу из другого — эта локализация для разработчика. Ровно потому, что среднестатистический пользователь — нелокализованный пользователь. Напоминаю, я говорю преимущественно о консоли разработчика, который вполне может ограничиться дефолтной локализацией своей консоли, и ограничить консольный вывод отладочной информацией. А логирование приложения выполнять как-то иначе, например исключительно на английском. Или не выполнять вообще.
Коротко говоря, дефолтная локализация консоли разработчика программной локализации не повредит, а помочь иногда может.
Ваше мнение понятно, право на существование имеет. Выбор подхода за разработчиком, наша мини-полемика ему в этом поможет. И давайте вот именно по этому вопросу на этом остановимся.
Коротко говоря, дефолтная локализация консоли разработчика программной локализации не повредит, а помочь иногда может.
Ваше мнение понятно, право на существование имеет. Выбор подхода за разработчиком, наша мини-полемика ему в этом поможет. И давайте вот именно по этому вопросу на этом остановимся.
Я исхожу из другого — эта локализация для разработчика.
А для разработчика можно вообще всей этой странной активностью не заниматься, если честно. В консоли все равно отлаживаться неудобно, а за пределами консоли (хотя у меня и в пределах не было особых проблем) в .net с Unicode просто все работает.
Исторически кодовой страницей Windows является CP1251 (Windows-1251, ANSI, Windows-Cyr)ANSI — это целая пачка национальных кодовых страниц
CP1251 — это конкретно российская кодовая страница, одна из набора ANSI
уверенно вытесняемая 8-битной кодировкой Юникода CP65001 (UTF-8Windows работает в UTF-16:
For compatibility with 8-bit and 7-bit environments, Unicode can also be encoded as UTF-8 and UTF-7, respectively. While Unicode-enabled functions in Windows use UTF-16, it is also possible to work with data encoded in UTF-8 or UTF-7
New Windows applications should use UTF-16 as their internal data representation.
Совет 1. Выполнять разработку текстовых файлов (программных кодов, текстовых данных и др.) исключительно в кодировке UTF-8.может лучше прислушаться к рекомендациям Microsoft?
ANSI — это целая пачка национальных кодовых страниц
CP1251 — это конкретно российская кодовая страница, одна из набора ANSI
Верно, но мне кажется вполне очевидным, что речь идет о русифицированной Windows.
может лучше прислушаться к рекомендациям Microsoft?
А вот это спорно. Не в том смысле, что MS ошибается, а в том, что рекомендации MS конкретно в этом случае противоречивы. Но вотпрямщаз я не готов сравнивать кодировки Юникода. Это тема отдельного поста.
Актуальные версии командной строки cmd.exe способны локализовать приложения«локализовать приложения» — это совсем про другое, это про перевод, национальные стандарты и т.п. Этим занимаются разработчики, а cmd.exe
Формально вы правы, но далее понятие уточняется: «На самом деле, правильнее говорить о локализации приложения в консоли — это важное уточнение».
Т.е. речь идет не о локализации приложения, а о локализации его отображения в консоли… бла-бла-бла. Коротко — локализация приложения в консоли. И да, даже в этом случае термин не корректен, поскольку речь может идти также и о национальном стандарте времени в консоли.
Но что делать? Не описывать же каждый раз объект и предмет двумя-тремя абзацами…
Т.е. речь идет не о локализации приложения, а о локализации его отображения в консоли… бла-бла-бла. Коротко — локализация приложения в консоли. И да, даже в этом случае термин не корректен, поскольку речь может идти также и о национальном стандарте времени в консоли.
Но что делать? Не описывать же каждый раз объект и предмет двумя-тремя абзацами…
НЛО прилетело и опубликовало эту надпись здесь
На самом деле, вы что-то делаете не так изначально.
PS> Echo ffffff ?????? // так выглядит та же команда в Windows PowerShell
Вот вам поведение PowerShell "из коробки":
(проверено на двух разных компьютерах, где ОС даже разные люди устанавливали)
Откуда у вас взялись знаки вопроса?
Не знаю, и вникать не хочу. Если вы заметили, я на этом внимание не акцентировал, и не предлагал убить дефолтную 5-ку. Полагаю, что это результат моих дефолтных установок. Пока мне не мешает, при необходимости поправлю. А в качестве иллюстрации правильности программной локализации как раз даже наоборот — помогает.
Что касается «делаете неправильно» попробуйте выдать chcp 1251, например, а затем chcp 65001, тоже например. В разных консолях. А после каждой chcp запустить код типа:
Результат вас удивит. В 5-ке вы получите
1251
1251
65001
65001
а в 7-ке:
1251
437 (скорее всего, потому что 437 — дефолтная, ну или другую текущую CP)
65001
437 (или опять же другую текущую)
Вот и вся проблема. Две абсолютно одинаковых команды не должны по-разному работать в разных версиях одной и той же программы.
Что касается «делаете неправильно» попробуйте выдать chcp 1251, например, а затем chcp 65001, тоже например. В разных консолях. А после каждой chcp запустить код типа:
Writeline(GetConsoleInputCP());
Writeline(GetConsoleOutputCP());Результат вас удивит. В 5-ке вы получите
1251
1251
65001
65001
а в 7-ке:
1251
437 (скорее всего, потому что 437 — дефолтная, ну или другую текущую CP)
65001
437 (или опять же другую текущую)
Вот и вся проблема. Две абсолютно одинаковых команды не должны по-разному работать в разных версиях одной и той же программы.
Не знаю, и вникать не хочу.
Печально.
Отчего так?
Оттого, что вы не хотите разбираться в том, о чем, собственно, ваш пост.
Мой пост не о PS Core. И не о PS. Если вы перечитаете первые пару абзацев, то возможно уясните, что у меня нет задачи дать строгий алгоритм, а указать на возможные проблемы, и возможные пути их разрешения. Что я и сделал.
Повторюсь. Косяк в дефолтной консоли — он мой, и не является, не должен являться проблемой остальных. А уж когда я с ним разберусь… это, в принципе, никого не касается.
Повторюсь. Косяк в дефолтной консоли — он мой, и не является, не должен являться проблемой остальных. А уж когда я с ним разберусь… это, в принципе, никого не касается.
Отдельно дополню. Знаки вопроса в 5-ке при вводе — мой косяк, мне кажется я это дал понять в тексте, и он несущественнен для сути поста. Он только мой. А вот косяки 7-ки, это косяки консоли. Они общие, поэтому я на них и акцентировался.
Две абсолютно одинаковых команды не должны по-разному работать в разных версиях одной и той же программы.
Почему вдруг? Вы никогда не слышали про breaking changes?
breaking changes абсолютно никакого отношения к рассмтриваемой ситуации не имеет.
Ну или если упереться в формальный термин, то в нашем случае breaking changes — это голимый косяк. Это примерно как однопоточное приложение признать потоконебезопасным.
Ну или если упереться в формальный термин, то в нашем случае breaking changes — это голимый косяк. Это примерно как однопоточное приложение признать потоконебезопасным.
breaking changes абсолютно никакого отношения к рассмтриваемой ситуации не имеет.
Почему? То, что случилось, это оно и есть.
Нет, не оно. «Оно» относится к ситуации, когда компонент рассчитан на взаимодействие с неким классом других компонентов. Тогда завляются требования, исполнение которых гарантирует корректное взаимодействие. Если таковые не исполняются, взаимодействие компонентов не гарантируется. Но возможно. Пожалуй, наиболее яркий пример — Windows 10. В которую и были внесены breaking changes, о чем было широко заявлено. Большиство простеньких приложений прокатывало, но более сложные, использующие функционал ОС по максимуму, судорожно начали лепить костыли. Ну и MS тоже в этом поучаствовала.
В нашем случае однм компонент взаимодействует с другим. ОС с консолью. Поэтому все костыли должны быть слеплены до релиза.
В нашем случае однм компонент взаимодействует с другим. ОС с консолью. Поэтому все костыли должны быть слеплены до релиза.
«Оно» относится к ситуации, когда компонент рассчитан на взаимодействие с неким классом других компонентов
Консольная оболочка — тоже такой компонент.
Да, я об этом и сказал. Но здесь речь идет о взаимодействие компонента не с классом компонентов, а одного с одним. ОС и консоль. Поэтому все брикинги должны быть убраны. Это невозможно, или затруднительно для класса компонентов (например для всех приложений под Windows при переходе на 10-ку), но обязательно для случая один на один.
Ну какой тут брикинг ченджс? Ребята, мы сделали новую прогу, но пара функций точно не работает, а еще процентов 50 мы точно не знаем. Удачного кодинга или юзинга!
Вы че, смеетесь? Или троллите меня? Я человек доверчивый, меня троллить легко — а вам ни славы, ни удовольствия.
Ну какой тут брикинг ченджс? Ребята, мы сделали новую прогу, но пара функций точно не работает, а еще процентов 50 мы точно не знаем. Удачного кодинга или юзинга!
Вы че, смеетесь? Или троллите меня? Я человек доверчивый, меня троллить легко — а вам ни славы, ни удовольствия.
Но здесь речь идет о взаимодействие компонента не с классом компонентов, а одного с одним.
Нет, о реакции компонента (PS) на команду.
Поэтому все брикинги должны быть убраны.
Да никому никто ничего не должен. С чего вы взяли? Вы так говорите, как будто вас кто-то заставляет на Core апгрейдиться. Вот я знаю, что у меня под ней не заведется несколько скриптов именно из-за breaking changes — и сижу на пятерке.
Да и вы не должны мне писать, однако пишете. И я не должен, однако пишу. Давайте-ка понизим накал — время жалко. Поэтому к делу.
Ваш пример опять неудачен, хотя бы потому, что не раскрыт. Попробую сделать это за вас. Ваши скрипты не заводятся по одной из трех причин:
1. Удалена команда. Случай редкий, поскольку снижена функциональность без объявления войны. Типичный breaking changes. Объявление обязательно, поскольку необъявленные брикинги чреваты судебными исками, и не всегда «As is» прокатывает.
2. Функционал команды изменен. Случай нередкий. Обычно в этом случае меняется и формат команды, включая имя. Просто для того, чтобы сохранить старую команду для обеспечения совместимости.
3. Функционал добавлен к другой команде. См. п.2
4. Функционал изменен без смены имени и формата. По каким-то неведомым причинам. Нетипично, но тогда это breaking changes и требуется объявление потому что… см. п.1. Где удобнее всего сделать? При вызове команды.
5. см. п.4 но без объявления — наш случай. Это косяк, потому что… см. п.1
Ваш пример опять неудачен, хотя бы потому, что не раскрыт. Попробую сделать это за вас. Ваши скрипты не заводятся по одной из трех причин:
1. Удалена команда. Случай редкий, поскольку снижена функциональность без объявления войны. Типичный breaking changes. Объявление обязательно, поскольку необъявленные брикинги чреваты судебными исками, и не всегда «As is» прокатывает.
2. Функционал команды изменен. Случай нередкий. Обычно в этом случае меняется и формат команды, включая имя. Просто для того, чтобы сохранить старую команду для обеспечения совместимости.
3. Функционал добавлен к другой команде. См. п.2
4. Функционал изменен без смены имени и формата. По каким-то неведомым причинам. Нетипично, но тогда это breaking changes и требуется объявление потому что… см. п.1. Где удобнее всего сделать? При вызове команды.
5. см. п.4 но без объявления — наш случай. Это косяк, потому что… см. п.1
Ваши скрипты не заводятся по одной из трех причин
И какая мне разница-то? Мне важно, что они не заводятся, и их надо чинить.
поскольку необъявленные брикинги чреваты судебными исками
Серьезно? На основании чего?
Серьезно. На основании предоставления продукта не соответствующего техническому описанию.
Процитируйте, пожалуйста, пункт binding agreement, в котором разработчик и/или издатель PowerShell Core обязуются соответствовать какому бы то ни было техническому описанию.
Процитирую, на всякий случай, ту лицензию, которую удалось найти мне:
PowerShell Core is released under the MIT license. Under this license, and without a paid support agreement, users are limited to community support. With community support, Microsoft makes no guarantees of responsiveness or fixes.
THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
(https://github.com/PowerShell/PowerShell/blob/master/LICENSE.txt)
Судебный иск? Я бы почитал обоснование-то, да.
Неа.
У вас нет на руках ни договора подряда, ни договора возмездного оказания услуг. Вы вообще не являетесь заказчиком в этих отношениях.
Единственный договор, на который можно сослаться в суде — это лицензионное соглашение выше. Оно имеет все признаки открытой лицензии и как следствие регулируется статьей 1286.1 ГК РФ.
Там нет ничего о "несоответствии техническому описанию" и вообще нет никаких обязанностей лицензиара.
еще раз.
п. 1.2
п. 1.2
Нет. У вас нет никакого заказа. Собственно, даже в статье об этом написано:
Вместе с тем, указанные варианты представляются не совсем применимыми к случаям покупки готового ПО.
В третий раз. п. 1.2.
1.2. К данной ситуации имеется и второй подход, который гораздо менее распространен, но и его стоит учитывать. Согласно данному подходу к правоотношениям сторон по лицензионному договору (!!!) по аналогии могут быть применены положения глав 37-39 ГК РФ об оказании услуг и подряде, что позволяет правообладателю ссылаться на недостатки результата работ.
дальше сами. Глазками.
1.2. К данной ситуации имеется и второй подход, который гораздо менее распространен, но и его стоит учитывать. Согласно данному подходу к правоотношениям сторон по лицензионному договору (!!!) по аналогии могут быть применены положения глав 37-39 ГК РФ об оказании услуг и подряде, что позволяет правообладателю ссылаться на недостатки результата работ.
дальше сами. Глазками.
К данной ситуации имеется и второй подход
К какой конкретно "данной ситуации", учитывая, что в конце статьи явно написано:
Вместе с тем, указанные варианты представляются не совсем применимыми к случаям покупки готового ПО.
Напомню так же, что чуть ниже процитированного вами текста идет ссылка на п. 6 ст. 13 АПК РФ (только он дает возможность применения глав 37-39 "по аналогии"), который звучит так:
В случаях, если спорные отношения прямо не урегулированы федеральным законом и другими нормативными правовыми актами или соглашением сторон и отсутствует применимый к ним обычай делового оборота
Однако в случае с PowerShell Core отношения явно урегулированы статьей 1286.1 ГК РФ, так что это все вылетает в трубу.
Прямо скажем, статья 1286.1 введена в 2014 году, а практика, на которую вы ссылаетесь — 2012, так что оно еще и неактуально.
А давайте вы лучше с судом поспорите- там ведь ссылки на решения есть. А если хотите актуальности — ищите ее сами.
А вот представьте — переход на Windows 10, и не одно приложение не работает. Ни одно! Как вы полагаете, было бы это breaking changes? Да ни фига, как бы эта винда не называлась — пусть даже «Windows XP чуть-чуть получше». Это была бы новая система. И к ней новые приложения. И никаких ченджей.
А вот представьте — переход на Windows 10, и не одно приложение не работает. Ни одно! Как вы полагаете, было бы это breaking changes?
Это называется "полная потеря обратной совместимости".
Только не обратной, а просто совместимости. Обратная совместимость — когда новое приложение для новой ОС, работает под старой версией ОС.
Обратная совместимость — когда новое приложение для новой ОС, работает под старой версией ОС.
наличие в новой версии компьютерной программы или компьютерного оборудования интерфейса, присутствующего в старой версии, в результате чего другие программы (или человек) могут продолжать работать с новой версией без значительной переделки (или переучивания).
Нет.
Что нет?
Вот выдержка с вашей же ссылки:
Сравните с моим:
Перевожу, если сразу непонятно:
Новое приложение, для того чтобы работать под старой ОС, должно сохранять старые функции, отсутствующие в новой.
Так же, как новый MS Office сохраняет старые форматы.
Вот выдержка с вашей же ссылки:
Обратная совместимость в программном обеспечении
Обратная совместимость применительно к программному обеспечению означает способность более поздних версий программы работать с файлами, созданными более ранней версией этой же программы или программы, реализующей те же алгоритмы, что и более ранняя версия. Так, например, в Microsoft Office присутствует поддержка целого ряда форматов, которые на данный момент почти не используются.
Сравните с моим:
Обратная совместимость — когда новое приложение для новой ОС, работает под старой версией ОС.
Перевожу, если сразу непонятно:
Новое приложение, для того чтобы работать под старой ОС, должно сохранять старые функции, отсутствующие в новой.
Так же, как новый MS Office сохраняет старые форматы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гарантированная локализация/русификация консоли Windows