[PATCH 0/1] MR5533: widl: Use hardcoded build time in TLB custom data.

[Brendan Shanks (＠bshanks)]

This makes builds reproducible, and matches the current MIDL behavior (except that MIDL's string representation inexplicably varies with the build machine timezone).

The new info_string used by WIDL: `Created by WIDL version 9.7 at Tue Jan 19 03:14:07 2038`

And the custom data section in a .tlb file created by a recent MIDL:
```
off 0: guid(DE77BA65-517C-11D1-A2DA-0000F8773CE9) value(Created by MIDL version 8.01.0628 at Mon Jan 18 19:14:07 2038)
off c: guid(DE77BA63-517C-11D1-A2DA-0000F8773CE9) value(2147483647)
off 18: guid(DE77BA64-517C-11D1-A2DA-0000F8773CE9) value(134283892)
```

The only detailed info about this change in MIDL (which happened years ago AFAICT) is from Chromium.
They have a script which processes TLB files to compare against previously-built artifacts (or something similar), and mentions the timestamp and timezone: https://chromium.googlesource.com/chromium/src/+/master/build/toolchain/win/...

They also have a rough Python 2 script to parse/dump TLB files, which is where the above MIDL output comes from: https://chromium-review.googlesource.com/c/chromium/src/+/693223

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5533

[PATCH 1/1] widl: Use hardcoded build time in TLB custom data.

[Brendan Shanks]

From: Brendan Shanks <bshanks(a)codeweavers.com>

This makes builds reproducible, and matches the current MIDL behavior
(except that MIDL's string representation will vary with the build machine
timezone).
---
 tools/widl/write_msft.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c
index 31e340e6bcd..b9a3d6664f2 100644
--- a/tools/widl/write_msft.c
+++ b/tools/widl/write_msft.c
@@ -2757,7 +2757,6 @@ int create_msft_typelib(typelib_t *typelib)
     const statement_t *stmt;
     const attr_t *attr;
     time_t cur_time;
-    char *time_override;
     unsigned int version = 7 << 24 | 555; /* 7.00.0555 */
     static const struct uuid midl_time_guid    = {0xde77ba63,0x517c,0x11d1,{0xa2,0xda,0x00,0x00,0xf8,0x77,0x3c,0xe9}};
     static const struct uuid midl_version_guid = {0xde77ba64,0x517c,0x11d1,{0xa2,0xda,0x00,0x00,0xf8,0x77,0x3c,0xe9}};
@@ -2813,11 +2812,13 @@ int create_msft_typelib(typelib_t *typelib)
         }
     }
 
-    /* midl adds two sets of custom data to the library: the current unix time
-       and midl's version number */
-    time_override = getenv( "WIDL_TIME_OVERRIDE");
-    cur_time = time_override ? atol( time_override) : time(NULL);
-    sprintf(info_string, "Created by WIDL version %s at %s", PACKAGE_VERSION, ctime(&cur_time));
+    /* midl adds three sets of custom data to the library:
+     * - 2147483647 (INT_MAX, previously the current Unix time)
+     * - midl's version number
+     * - a string representation of those
+     */
+    cur_time = 2147483647;
+    sprintf(info_string, "Created by WIDL version %s at %s", PACKAGE_VERSION, asctime(gmtime(&cur_time)));
     set_custdata(msft, &midl_info_guid, VT_BSTR, info_string, &msft->typelib_header.CustomDataOffset);
     set_custdata(msft, &midl_time_guid, VT_UI4, &cur_time, &msft->typelib_header.CustomDataOffset);
     set_custdata(msft, &midl_version_guid, VT_UI4, &version, &msft->typelib_header.CustomDataOffset);
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/5533

[Elizabeth Figura (＠zfigura)]

I'm not necessarily opposed if we're matching MIDL, but... wasn't the point of WIDL_TIME_OVERRIDE already to make reproducible builds? And do we really want to match MIDL here if it means giving the wrong time? It seems like a bit of a misfeature...

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5533#note_68881

[Brendan Shanks (＠bshanks)]

Yep that is the point of WIDL_TIME_OVERRIDE, but I think the thrust of MIDL's change (and this one) is that there's almost no benefit to embedding the build time inside TLB files, so let's just make it always reproducible rather than requiring an environment variable.

(With a possible contributing factor being that the build time uses a 32-bit Unix timestamp, so it will be wrong starting in 2038 anyway)

And I guess the ecosystem of things that parse TLB files is fragile enough that they couldn't remove the timestamp, instead it's just set to a garbage value.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5533#note_68894

[Elizabeth Figura (＠zfigura)]

That makes sense to me.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5533#note_68915

[PATCH 0/1] MR5533: widl: Use hardcoded build time in TLB custom data. - approved

[Elizabeth Figura (＠zfigura)]

This merge request was approved by Elizabeth Figura.
-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5533

[PATCH 0/1] MR5533: widl: Use hardcoded build time in TLB custom data. - approved

[Huw Davies (＠huw)]

This merge request was approved by Huw Davies.
-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5533