JEDI Windows API Library - Project JEDI Wiki (original) (raw)
Windows API Tracking Policy
JEDI API consists mainly of older Windows x32 native headers translated by Marcel van Brakel. More and more newer definitions were added in an evolutionary process.
Because the translation is done manually (only parts can be translated automatically but need review) the MS Windows SDK cannot be translated completely. So only parts have the new API functions of e.g. Windows Vista or Windows 7. Other parts are really old and deprecated but left for compatibility (usually Windows 9x).
Platform SDK
Platform SDK is deprecated and replaced by Windows SDK.
Windows SDK
Windows SDK now includes Platform SDK and .NET Framework SDK.
ChristianWimmer 21:13, 31 January 2010 (UTC):
People don't usually care about the version but instead they need a set of Windows API functions they can call and are happy about. So my idea is not to translate the whole Windows SDK but instead translate useful parts of the Windows API. As a side effect of JWSCL I translate headers that are needed by the library.
Conrad T. Pino 22:45, 31 January 2010 (UTC):
OK, the policy is on demand. The consequence is determining if Project JEDI can support a given developer requires a substantial time commitment by the developer because Project JEDI doesn't publish which Micrsoft SDK level applies to a given unit.
I'd like to point out the API tranlsation isn't done in a vacuum; some Microsoft SDK MUST be referenced to do the work. All I suggest is we capture the referenced SDK level in the source file and from time to time we extract that information and publish that on a single page somewhere. The data should be structured so machine capture is possible.
ChristianWimmer 18:28, 1 February 2010 (UTC):
This is a good idea. However, getting the SDK level of the current units is a hell of work, and what are the immediate advantages?
The predicate principle is bad information is better than no information. Tranforming bad into good is easier than creating good from nothing.
I'm NOT suggesting reworking current units except as self entertaiment should someone be so inclined. The only exception I'd consider is reworking JEDIedit to markup existing current units to "unknown SDK level".
The real value is establishing the standard and applying that to future practice. Time and the normal improvement cycle will take us quite far. At some time someone will become motivated to complete the process when the number of "unknown SDK level" units becomes small.
Should the SDK conformance level become fully known then replacing dynamic linking with SDK level conditional compilation similar to Delphi level conditional compilation becomes possible.