C language > Work in progress

fSDK© - Frankie's SDK for PellesC

(1/12) > >>

To upgrade compiler with fSDK kit download installer from github and run it
fSDK can be browsed on GitHub

- 05/Jan/2019 -- V. (05.Jan.2019)
            - Update dependencies for new PellesC V.9.00
              - Fixed intrinsics
              - Fixed conditional compilation for V.8.00 compatibility
              - Minor general fixes
            - Fixed header xnamath.h
            - Added missing IID's in mmdeviceapi.h and Audioclient.h
            - Added new DXGI's
            - Fixed reference to bthprops.cpl in bthprops.lib
            - Added Backup feature to backup headers and libraries folders
            - Minor fixes and general cleaning

- 11/Feb/2018 -- V. (11.Feb.2018)
  - Fixed header MsHtmlC.h
  - Added WMI Samples
- 12/Feb/2017 -- V. (12.Feb.2017)
  - Fixed header xmllite.h (discovered by TimoVjl).
  - Added XML demo from TimoVjl
- 28/Gen/2017 -- V. (28.Jan.2017)
  - Fixed symbol 'THREAD_MODE_BACKGROUND_BEGIN' in winbase.h (discovered by Grincheux).
  - Added symbol '__FSDK__' equated to the current version in hex (0x00010200), to be used for conditional compilations to discriminate use of fSDK or standard PellesC SDK (where of course __FSDK__ is not defined).
  - Fixed minor bugs in headers and made cosmethic changes.
- 10/Dec/2016 -- V. (10.Dec.2016)
  - Fixed EXTERN_GUID macro
  - Fixed many headers for system include uniformity
  - Minor aesthetic fixes
  - Added Media Foundation demo: capture video to a file
- 04/Dec/2016 -- V. (04.Dec.2016)
  - Added more DX8 headers and libraries
  - Added DX8 Donuts3D demo
  - Fixed some bugs in headers
- 26/Nov/2016
  - Fixed former bugs.
  - Added more headers
  - Added DirectX support for DX8, DX9, DX10 and DX11
  - Added redistribuitable runtime for DirectX 8, 9, 10, 11
  - Experimentally added support and runtime for OpenGL (FreeGlut).
  - Modified Setup for minimal, full and custom installation
  - Added more Directx and OpenGl samples
- 20/Nov/2016 - Fixed some include files.
  - Added more DirectX headers and libraries
  - Added more samples
13/Nov/2016 - Fixed include files
              Added extended support DX3DEx Headers and libraries and also 2 new samples Midiplayer and a directx sample
07/Nov/2016 - Fixed libraries for __cdecl functions and some fixes also to headers
 - Added Ribbon IID's definition
 - Fixed problems for multiple GUID's definitions in UIRibbon.h
 - Added definition <#define __uuidof(x) &IID_##x> in objbase.h
 - Fixed macro IsEqualPropertyKey in propkeydef.h
 - Added Ribbon samples
14/Sep/2016 - Fixed winNt.h and winbase.h headers. Intrinsics definitions should be Ok now.
(download it from GitHub).
- 10/Sept/2016 - Fixed headers, libraries rebuilt fixing problems.

This is a challenging project targeting the port of the last complete MS SDK to pellesC.
The collection of headers is actually composed of 1381 headers. Many of them are a
replacement for outdated headers. The vast majority are completely missing from actual
PellesC is an excellent compiler suite for windows, and includes the most relevant, and
most common headers, enough to compile almost all projects.
But nowadays sources available around make use of functions and interfaces that are'nt
in the actual distribution. This make very difficult to compile them under PellesC
set of headers and libraries.
This installer will made them available in the compiler include\win directory to let
you use them in your programs, including fGdiPlusFlat.h to use GDI+ under plain 'C'.

The setup also installs an Updated version for strmiids.lib (normally available only
from MS sdk) This version contains all MS GUID's at this date.
It installs also the libraries quartz.lib and Ddraw.lib.

You'll understand that I couldn't have deep checked all headers! And even if I can compile and run all my projects I expect anyway problems around.
To solve them I need your cooperation. Check against you projects and report errors possibly with a small sample that reproduce the problem.
I'll wait your feedbacks to fix the package then move it to contributions.

The keypoints of this project are:
    - Compilation speedup:
        - Because headers will be used in a plain C compiler all references, and conditional
          compilation related to C++, has been removed.
        - For similiar reasons have been removed all conditional compilation related to MIDL,
          PREFAST and annotations.
        - These headers will never be intended for MAC & relatives. So any conditional compilation
          and references to _MAC has been removed.
        - These headers are intended for PellesC, so almost all references to _MSC_VER have
          been translated to __POCC__ equivalent.
    - MS compliance.
      Because many sources available have been written for MSVC compilers the headers have been
      'adjusted' to fit MS requirements. Some of the technical problems found are:
        - Missing __declspec(selectany). MS is used to multiply define symbols tagging them with this
          specifier. This creates a kind of a 'weak' symbol that the compiler should ignore when
          multiply defined. Note that the PellesC linker have the option '/FORCE:MULTIPLE' that could
          mimic the behaviour of __declspec(selectany), but, opposed to the specifier working way, it
          will ignore *all* multiple definitions, de facto masking also eventual errors.
          The solution actually used is the conversion of all symbol instances with an equivalent
          This should work well for base types (int, char, float, double, etc), but could be a problem
          with complex types (structs, unions, etc).
        - GUIDs, PROPKEYSs and other complex types that are tagged by __declspec(selectany).
          They are required for reference on each source file that includes the header.
          The solution used is to tie them to conditional definition. The symbols are normally defined
          as 'extern', and instanziated only if the preprocessor symbol 'INITGUID' is defined. Defining
          the symbol in only one source, before the header #include, creates a single instance of the
          symbol while there are multiple extern references.
    - ANSI C compliance.
      Many native MS headers are write with C++ in mind, and for this reason are not ANSI compliant.
      I.e. structs, unions, class, enumerations and global namespaces are all coincident in C++.
      Consider these 2 declarations:

--- Code: ---            struct foo
                int bar;
            typedef struct
                int bar;
            } foo;

--- End code ---
      Under C++ you can declare a variable of type 'foo' indifferently with both declarations because
      the global and struct namespaces are coincident meaning that the type 'foo' will be defined in
      any case, and the statement:

--- Code: ---            foo mystruct = {0};

--- End code ---
      will not produce errors with both declarations.
      But in C, in the first case, the type 'foo' is defined only in the structs namespace (or tagnames namespaces, to be sharp, and because tags are used also from unions and enumerations, the namespace is shared), and the
      statement above will produce an error. To make it work it should be:

--- Code: ---            struct foo mystruct = {0};

--- End code ---
      In the second case it will work for both.
      The solution used is a tweeking of declarations:

--- Code: ---
            typedef struct foo
                int bar;
            } foo;

--- End code ---
      The above code defines 'foo' in both namespaces and fix the ANSI compliance  (or at least should...).
    - Porting of C++ only headers.
      Many headers are C++ only, even if their content can be used under plain C. An example of this
      type of files are gdiplus.h, Ddraw.h, etc.
      In the port process of C++ headers to C the helper classes have not been translated.
      Not all C++ files are currently translated, but they are included in the distribution generating
      an error "C++ only header!". If you encounter one you can translate it yourself and then make it
      available, or ask for translation and wait. In any case if the header contains only 'helper' classes don't expect
      it will be taken in consideration.

The installer for new headers and libraries, 32 and 64 bits, are available from GitHub.

Great! Thanks! :)

Thanks Alex  :)

Big thanks to you.

Thanks Timo  :)


[0] Message Index

[#] Next page

Go to full version