Куча говна / Говнокод #25434 Ссылка на оригинал

0

  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 KGeist, (Updated )

Комментарии (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.

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

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

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?


    8