[Question] Use of old FDI.h with Microsoft copyright notice as reference
Dear all, Sorry to bother, but I could not find a clear answer and would like to check before doing any Wine work based on material with an unclear legal status. I was looking into Wine's implementation of FDI and cabinet.dll. While looking at code examples using FDICreate and FDICopy, I stumbled upon an old GPL project called CapiTel. The FDI.h contained in this project has many useful explanations for constants and functions that are poorly documented in the Microsoft Learn Win32 API reference, as well as in Wine's API reference. However, the file says: Copyright (C) Microsoft Corporation 1993-1997. All Rights Reserved. I was wondering whether it is OK to use information learned from this header to document the Wine API. I was also wondering whether it would be acceptable to patch some of the functions based on what I learned from this header. Thanks in advance for your help and guidance, David Carrasco Flores
Am Donnerstag, 30. April 2026, 19:41:53 Ostafrikanische Zeit schrieb David CF via Wine-Devel:
I was wondering whether it is OK to use information learned from this header to document the Wine API. I was also wondering whether it would be acceptable to patch some of the functions based on what I learned from this header.
Learning from headers is OK. Facts and interfaces aren't copyrightable or using them is fair use, depending on jurisdiction. What is NOT ok is copypasting from a copyrighted header. What is also NOT ok is looking at incompatibly licensed *implementations*. I sense that your concern is that you don't know how the header got into public view, and that it might be leaked code. Looking at leaked implementations would be a no-go, but a header shouldn't contain implementation code. My best guess is that the header came from an OS/2 SDK. Maybe you can find a more official source for it. The ideal approach is something like this: 1) You have a real world application that does not work with Wine's cabinet.dll 2) The documentation you found in this header offers an explanation of what the application needs 3) You write tests in dlls/cabinet/tests that demonstrate the behavior of the native DLL 4) You implement the behavior in Wine. Somewhere in step 3 or 4 you'll likely need additional defines. Add them to Wine's header by typing them yourself, but don't copypaste from Microsoft's header.
Stefan Dösinger wrote:
Am Donnerstag, 30. April 2026, 19:41:53 Ostafrikanische Zeit schrieb David CF via Wine-Devel:
I was wondering whether it is OK to use information learned from this header to document the Wine API. I was also wondering whether it would be acceptable to patch some of the functions based on what I learned from this header. Learning from headers is OK. Facts and interfaces aren't copyrightable or using them is fair use, depending on jurisdiction. What is NOT ok is copypasting from a copyrighted header. What is also NOT ok is looking at incompatibly licensed *implementations*.
I sense that your concern is that you don't know how the header got into public view, and that it might be leaked code. Looking at leaked implementations would be a no-go, but a header shouldn't contain implementation code. My best guess is that the header came from an OS/2 SDK. Maybe you can find a more official source for it.
The ideal approach is something like this:
1) You have a real world application that does not work with Wine's cabinet.dll 2) The documentation you found in this header offers an explanation of what the application needs 3) You write tests in dlls/cabinet/tests that demonstrate the behavior of the native DLL 4) You implement the behavior in Wine.
Somewhere in step 3 or 4 you'll likely need additional defines. Add them to Wine's header by typing them yourself, but don't copypaste from Microsoft's header.
Yes, indeed I was wondering if learning from a header that could have been leaked might suppose a problem. I wanted to understand the types and the return calls better than what the MS Learn Win32 API and the Wine API provided, so I could trace better where Wine's implementation was not behaving as it should. My case scenario is a bit the opposite of what you imagined: I have a binary and a dll from Wine that crashe when using the call to the native cabinet.dll, whilst they end gracefully with Wine's cabinet.dll. So Wine's cabinet.dll implementation seems to be more flexible and forgiving than the native one. I have 2 goals: 1) Document better what has already been implemented and leave some documentation/hints on the behavior that the unimplemented parts are expected to have. 2) When possible, go down the rabbit hole and trace down the point where the callback differs from the native DLL and if possible fix it. I am glad to hear that learning from the headers is not a problem. After reading your message I looked into it a bit more and found that the header belongs to the "Cabinet Software Development Kit" from March 20, 1997. I found the whole SDK, as well as a history/changelog of the cabinet.dll since it was created in 1993. So I guess for my purposes it is a valid resource then. Thanks for your quick response!
participants (3)
-
David CF -
dcf1007＠gmail.com
-
Stefan Dösinger