1. Куча / Говнокод #25434

    +3

    1. 1
    MSDN: To obtain the full version number for the operating system, call the GetFileVersionInfo function on one of the system DLLs, such as Kernel32.dll

    В Windows функции вроде GetVersion задепрекейтили (и остальные более новые функции из SDK) и теперь они всегда возвращают "Windows 8" в том числе на десятке, если приложения не манифестить или ещё чего (а манифестить не всегда возможно, если допустим, разрабатывается плагин под другой софт). В итоге в API куча непонятных правил и разных ЕСЛИ, и нет уверенности в том, реальную ли версию Винды нам возвращает функция, или это опять какой-то shim.

    С появлением rapid release cycle в Windows и автоапдейтов появляется проблема: новые апдейты постоянно ломают ранее рабочий софт. Для этого нужно делать workaround'ы: смотреть какой там у нас билд (1803? 1809?) и включать нужный костыль. Видимо, самим в Microsoft это надоело, что они на полном серьёзе предлагают смотреть file version у каких-нибудь системных файлов в системной папке, чтобы узнать версию ОС наверняка. Официальный говнокод от Майкрософт.

    Запостил: KGeist, 08 Марта 2019

    Комментарии (11) RSS

    • пиши под UWP.net, теки и не думай о версии Windows.

      Всё равно современные программисты слишком тупые чтобы писать насях
      Ответить
      • нахера казе баян. Хорошо что не сказал что "современные программисты не знают как программировать калькулятор Электроника К-61 в байткоде" (или какой там был не помню уже)
        ---------------
        это все архаика никому уже не нужна. Используй ум китайцев, они читают ироглифы целяком а не слова по буквам поэтому тратаят в 100 раз меньше времени что бы получить тотже обьем информации
        Ответить
        • Программируемые калькуляторы не нужны. Сейчас почти у каждого в кармане есть маленький конпуктер на который можно поставить "Python", 'J' и что там ещё. А вот на "Си" написано большое количество программ и до сих пор пишут, и будут писать, потому что язык простой, быстрый и реализован для большинства платформ.

          > Используй ум китайцев
          Именно поэтому я за 'APL'.
          Ответить
      • Если в софте используется что-то нетривиальное (напр. нативная библиотека для чего-то высокопроизводительного), а это происходит намного чаще, чем хотелось бы, то C# превращается в С, т.к. нужно знать много чего, чтобы правильно написать обёртку вокруг нативного кода. Там даже всё сложнее становится, чем просто писать на Сях, т.к. может быть какой-то misalignment между структурами Си и их аналогами в C#, или misalignment сигнатур (cdecl/stdcall), дебажить переходы между нативным кодом и рантаймом .NET куда сложнее; также нужно учитывать рантаймные факторы вроде сборщика мусора (он может удалять коллбэки, прокинутые в Си, если не заrootить лямбды, он может у нас перед носом перемещать объекты и Си-сторона будет ссылаться на невалидную память и т.д.)

        Т.е. если задача -- простенькая, когда хватает стандартных либ, то .NET сойдёт. Но если задача -- какой-то реальный конкурентный продукт, то я бы поспорил, что сложнее -- писать сразу на С/C++, или городить многоэтажные костыли через .NET (C# => C/C++ => C#), где всё склеено на соплях. А если потом выходит новый апдейт Windows и что-то сломалось на низком уровне, то C#-only программист просто не осилит придумать костыль-workaround, и будет таращиться как баран на новые ворота
        Ответить
        • Если вам действительно нужно общаться с нативной библиотекой через P/Invoke, и COM интерфейса у нее нет (что странно конечно) то вы попадает в 1% тех, кому нужно понимать си и win32api.

          Подавляющее большинство программистов это вебмакаки или формошлепы
          Ответить
          • > ком интерфейса нет
            Дык у большинства сишных либ нет ком интерфейса. Ибо реализовывать его с сишной стороны - это наказание для грешников в аду.
            Ответить

    Добавить комментарий