none
INF DriverVer= mm/dd/yyyy Requirments Verification. RRS feed

  • Question

  • I am slightly confused here.

    INF DriverVer Directive (Windows 10 hardware dev):
    https://msdn.microsoft.com/en-us/library/windows/hardware/ff547394(v=vs.85).aspx

    From the link:
    'mm/dd/yyyy
     This value specifies the date of the "driver package", which includes the driver files and the INF.
     This date must be the most recent date of any file in the driver package.'

    Everything I read here including
    https://msdn.microsoft.com/en-us/library/windows/hardware/ff544840(v=vs.85).aspx
    https://msdn.microsoft.com/en-us/library/windows/hardware/ff539954(v=vs.85).aspx
    Seems to indicate that the .inf file is considered to be part of the 'Driver Package'.

    So if the .inf file is part of the 'Driver Package', and one does a StampInf /d 01/01/2016
    on it on 01/02/2016 then the mm/dd/yyyy component of the DriverVer= line is in fact 01/01/2016
    BUT the date on the .inf file is now 01/02/2016 because StampInf changed the file.

    This does not seem right to me.
    This can only be right if the .inf file is NOT considered to be part of the 'Driver Package'.

    Is the .inf file really part of the 'Driver Package'?

    The reason I am asking this is I have a lot of drivers to create installs for
    (Non-PNP kernel mode and PNP kernel mode, Windows 7, Windows 8.1 and Windows 10)
    and cannot use the DriverPackage facilities within Visual Studio 2015 for very valid reasons.

    Thanks.

    Tuesday, February 16, 2016 5:21 PM

Answers

  • An INF is considered part of the driver package. In your example, why wouldn't you pass StampInf the current date?
    Friday, February 19, 2016 7:42 PM

All replies

  • An INF is considered part of the driver package. In your example, why wouldn't you pass StampInf the current date?
    Friday, February 19, 2016 7:42 PM
  • Thanks Jason.

    Since you answered my question the only polite thing to do is to answer yours.
    By the way I do believe your answer is correct.

    The whole DriverVer= line thing has become very confusing to me.

    The mm/dd/yyyy component of the DriverVer= line:
    1.) Stampinf changes the time stamp of the INF file to NOW (the date / time that stampinf was run against the INF, GMT).
    2.) If the INF file is considered to be part of the 'Package', and its mm/dd/yyyy portion of its time stamp
        then the mm/dd/yyyy must always be the date of the INF file (assuming one runs StampInf).
    3.) Of course the usage of Stampinf is good to prevent the condition where Inf2cat (which interprets the
        mm/dd/yyyy as UTC) errors can occur because StampInf uses GMT.
    4.) Stampinf is built into the 'Driver_Package' projects (via MSBuild). This of course is also a good
        thing but just happens to not be good for my scenario.

    The 'optional' 'version' number ([,w,x,y,z).
    1.) This is not a version number, it is now treated as a time stamp.
         Yes I am aware that a version number (like 2.5.25.122) will actually work.
    2.) It is optional yet StampInf will not stamp an INF file run without access
        to a 'version' number, either on the command line (-v), from a STAMPINF_VERSION
        environment variable or from the Ntverp.hNtverp.h file.


    I have a very large software suite I have written and maintain for a client.
    There are of course drivers involved.

    I do not use the Driver_Package facilities in VS when I actually build the drivers.
    This has to do with simplifying the creation of the installations for the suite supporting
    Windows 7 through Windows 10 (x68 and x64).

    The 'Build' for the suite is currently automated (Via a front end over MSBuild). It is not
    built via VS.

    When the current code signing certificate expires the driver signing requirements will change.
    (http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx)

    My original post was generated because I am trying to get ahead of the game (before the cert expires). I thought
    I would start from the ground up.

    Thanks again.

    Tuesday, February 23, 2016 3:44 PM