Pelles C forum
C language => Work in progress => Topic started by: frankie on March 22, 2014, 08:19:53 PM
-
I spent a couple of hours to look on how to directly import native MS headers in PellesC.
The discrepancies are:
- standard headers for C99 and C11 compatibility
- Problems on Math due to C99 and C11 extensions
- An apparently misuse of pasting operators in driverspecs.h (called by winNT.h)
The first point to consider is that PellesC is strictly compliant with C99 and C11, MS VC++ not! It includes C11++ that, unfortunately is not compatible with C11. In plane words the standard header layout is completely different from that of MS, things are declared in different stdxxxx.h files and this creates some problem.
The math type complex is a basic type for C99/C11, while MS defines it as a struct. This generates errors using the MS math.h header.
In driverspecs.h there are the lines:
#define __drv_out(annotes) __post __$drv_group(##__drv_nop(annotes))
and
#define __drv_when(cond, annotes) \
__drv_declspec("SAL_when(" SPECSTRINGIZE(cond) ")") __$drv_group(##__drv_nop(annotes))
Where the pasting operator (##) is not prepended by anything, and this is an error as stated also on MSDN help. This error produce a series of warnings of this type:
C:\PellesC\Include\winnt.h(1202): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
The problem can be easily solved by setting off the warning using a pragma, or by modifying the original MS def in driverspecs.h as follows:
#define __drv_out(annotes) __post __$drv_group(__drv_nop(annotes))and
#define __drv_when(cond, annotes) \
__drv_declspec("SAL_when(" SPECSTRINGIZE(cond) ")") __$drv_group(__drv_nop(annotes))
Moreover in "shellapi.h" there is this line
// PATH = c:\windows\system32;C:\windows;c:\;C:\Program Files\Compilers\
which end with a backspace that triggers the warning:
C:\PellesC\Include\shellapi.h(666): warning #1063: Single-line comment contains escaped new-line.
To solve it edit shellapi.h adding a space at the end of the line.
Anyway to use the windows headers file is possible. They can live along with PellesC, and is possible to compile using directly the standard MS headers.
Now I will explain how to, of course there will be other problems that I still have not discovered compiling my sources.
I used the SDK WIN7 SP1.
To use Headers strictly follow the instructions here (http://forum.pellesc.de/index.php?topic=6136.msg22344#msg22344).
Let me know what problems you encounter.
-
Why touch to PellesC include when include path can changed as project based ?
Or in register or XML.
Maybe %PellesCDir% is important too for pomake ?
@Frankie
poide needs second copy as to new include/lib folder
\
\bin\poide.exe
\bin\Intl\rsrc0009.dll
\bin\AddIns\
\include\
\include\Win\
\lib
\lib\Win\
\lib\Win64\
other bins must be in PATH
This way we can have untouched PellesC and WSDK version in use ?
Any comments ?
-
Hi Timo,
Just because I have seen that some directories seems to be hardcoded in the compiler, or in the project files (.ppj and .ppw).
In this case when trying to compile existent projects it seems to look in the original directories :P
Could you make some checks?
I have already found something to be touched in "stat.h" and "strsafe.h".
Does it works in WIN64?
-
Just because I have seen that some directories seems to be hardcoded in the compiler, or in the project files (.ppj and .ppw).
Hardcoded %PellesCDir% only in poide's internal make. pomake can use %PellesCDir%.
PellesC poide with option -xml it is easy to make another copy of PellesC folder for testing environment and copy WSDK files into it. No messing with original folder at all.
-
Thanks Timo! ;)
I have made some more checks and discovered that is enough to replace headers in Include/Win directory.
All other files must remain that coming for PellesC distribution.
I'll write a detailed HowTo later.
Basically PellesC works with no problems with MS headers, apart the small hacking indicated in my first post and some other I have found.
For me is clear that the headers packed in the PellesC distribution are there just to install a ready to run compiler suite.
Infact the SDK's could not be redistribuited, and downloading an SDK install it and use is not so simple to explain to first time users. That's why Pelle make the decision to include a subset of headers, that IMHO are still enough unless you need a very advanced library or feature :P
But the point is, considering that Pelle should know that his compiler suite could use MS headers, he has not made public the feature for at least the advanced users... :o
New incompatibility are from the undeployed __declspec(selectany) and some other small issues that I'm hacking.
I have also copied new libraries in the lib folder and they works OK, unless the uuid.lib that triggers a linker error for an 'unknown codeview symbol 0x00). No problem compiling without debug information. Unless you don't need a very recent UUID you can still use the original library when compiling debuggable executables.
Last, to all PellesC users, I don't understand why nobody give any feedback. Is this issue of any interest only for me and Timo? :-\
(I could say that me and Timo know how to make it, so .... why do we have to waste time to write posts about it? ;D )
More seriously this is the main reason of irritation for Pelle, and I have to fully agree with him...
-
Hi Frankie and Timo,
Just want to say YES, this is a good initiative, and you are doing a very good job (no thumbs up icon here - MODERATOOOOOOR!!!!!)
-
Although, I have not had need up to this point for more than what is included in the standard Pelle's download, I appreciate the fact that if I do in the future want to include some of the missing elements of the windows SDK in my applications I can refer to this thread and get things up and running quickly.
Thanks Frankie and Timo for your time and effort on this! :D
JJ2007 - You can select the thumbs up from the Message icon drop down in the Post reply editor.
-
Thanks to all :)
But the feedback we need is on other possible issues. I'm still looking for other drawbacks compiling and recompiling my projects that could don't include all possible headers/libraries, or the one you may have used in your application (header or library, console or GUI functions, etc.).
What we need to help us is that you experiment on your system recompiling your projects and reporting the problems if any.
-
uuid.diff from PellesC uuid.lib and WSDK 7.1 uuid.lib
and uuid_1.lib generated with from WSDK uuid.lib
-
JJ2007 - You can select the thumbs up from the Message icon drop down in the Post reply editor.
Done. The Masm forum, which also uses SMF, has a better (IMO) icon list, see here (http://masm32.com/board/index.php?topic=3035.msg31553#msg31553) for example.
-
Thanks Timo.
Anyway the the linker problem seems to be related only to the debug section of the executable, that contains a symbol code unknown to PellesC codeview. I think this is from the new MS revisions of CodeView that are not pubblic (it's long time that MS doesn't pubblish an updated documentation). Probably a pdb reference or a new code for OLE/AUTO debuug.
So it should be safe to use it for release versions (without debugging info), or at least they can use Timo's library made with polib.
-
As pocc.exe support AMD64/x64, it is possible to test those WSDK headers for 64-bit too in 32-bit environment and with x64 libs linking is possible too when 64-bit libs are copied from lib\x64 to lib\Win64 folder.
With this AddIn Create/Open 32-bit project to 64 bit project (http://forum.pellesc.de/index.php?topic=4467.msg16682#msg16682) project is possible to copy to 64-bit version easily.
EDIT:
StrAlign.h line 113 without <wchar.h>#endif // _PREFAST_
wchar_t * wcscpy(wchar_t * dst, const wchar_t * src); //<- insert this
return wcscpy(Destination, Source);
#pragma warning(pop)
FixHdrLst.zip for testing. run it in PellesC base dir, it uses include/Win/ path and fix driverspecs.h and Stralign.h as Frankie shows.
-
Timo the insertion of wchar was already in the instructions, but the list numering was missed. It is the point 10.
I added numbering now.
The inclusion is on line 98 because if you define '_STRALIGN_USE_SECURE_CRT=1' also the function 'ua_wcscpy_s' is defined as 'wcscpy_s' and then requires whchar.h definitions.
Anyway the best place for the inclusion should be at top of the header just after the module symbole definition:
#if !defined(__STRALIGN_H_) && !defined(MIDL_PASS)
#define __STRALIGN_H_
#include <wchar.h> //Line 46 of WIN7-sp1 SDK
Anyway considering the views and that up to now just 3 peoples downloaded the utility doesn't seem that this argument is of so big interest... :(
-
pobr.exe doesn't like WSDK header files :(
Those f... annotations >:(
-
pobr seems to work for me :(
Have you used the /W switch for windows mode?
-
For example, if someone write MessageBox( and what (s)he see ?
With WSDK:
WINUSERAPI int WINAPI MessageBoxA( __in_opt HWND hWnd,
With PellesC headers:
int MessageBoxA(HWND hWnd, LPCSTR lpText, LPCSTR lpCaption, UINT uType)
-
I see... >:(
But this is more a bug of PellesC Info Browser than a problem with annotations...
Why the browser stops including text? >:(
Is the same problem that I get when I write a more complex piece of code, moreover the browser aborts silently an you have no more browse info anyywhere. Even the functions pane doesn't show all functions in the file >:(
-
Well, finally back with my old user name... Didn't much like having my real name up there for everyone to see.
Anyway... You're going to run into stuff like this a fair bit. Some apparently minor thing will fester itself into a full blown deal breaker. As I'm sure you know I've tried doing this several times over the years, never with much success.
You have two problems here... Headers and Libs. Even if you get the headers to load up error free (bearing in mind that "Compiles" does not imply "Works") you're still going to have the problem of missing imports from the Pelles C libs. Windows API has added more than 500 new calls since most of those libs were created so simply importing the headers is not going to give us magical access to the newer imports in the 2010 and 2013 SDK, we'll just end up with a huge mess of linker errors.
What I'd really like to see is a tool like they had for Turbo Pascal and later for Delphi that would basically read and transform the Windows headers automatically. Granted the transformation was not 100% but the issues were relatively minor and could be dealt with as we found them. Since the transforms from VC++ to Pelles C are far simpler than from VC++ to Pascal I see no reason this can't be done.
Ideally, downloading PellesC would not include Windows Develpment (headers and libs) at all. Instead, we would get command line tools and scripts (.bat?) to read the SDK headers and libs and transform/import them automagically at install time. If we got a newer copy of the SDK, just run the script again and we're all up to date. For Pelle this simplifies his updates since he now only needs to update the utility, not the headers and libs themselves.
But the only person who knows exactly how to do it is Pelle and he remains (strangely) silent...
-
Welcome CommonTater :D
Have you now working PellesC environment for WSDK 7.1 ?
What libraries makes you those harms ?
What real problems are ?
Is some where open source project to test against problems ?
--Timo
BTW: those who want to tackle with WSDK8:#include <excpt.h>
typedef
_IRQL_requires_same_
_Function_class_(EXCEPTION_ROUTINE)
EXCEPTION_DISPOSITION
NTAPI
EXCEPTION_ROUTINE (
_Inout_ struct _EXCEPTION_RECORD *ExceptionRecord,
_In_ PVOID EstablisherFrame,
_Inout_ struct _CONTEXT *ContextRecord,
_In_ PVOID DispatcherContext
);
typedef EXCEPTION_ROUTINE *PEXCEPTION_ROUTINE;very nice C code, isn't shit ?
-
Welcome CommonTater :D
Thanks...
Nope, still not getting it to work. I'm going to try Frankie's little tool later today.
But, as I point out, merely importing the headers is not sufficient. If we are bringing in new functionality (say, DRM, for example) we're going to have to translate the libs for it as well.
This is why I suggested a tool that does this automagically. It's a huge and tedious job and if we can automate at least the common changes it's going to save people a lot of time.
It would also help if we could put together a downloadable list of headers, with known changes that we can use as a starting reference. Listing them in the forum is ok, but eventually that can become a tedious and confusing search.
Something with the name, the line number and replacement line like...
msheader.h (100) \\ path = d:\ \n
msother.h (5655) PWCHAR ptufunc(WCHAR test);\n
... and so on, would be an enormous help.
Done correctely this could eventually become a translation script to be read and applied by a conversion tool. Initially it will be a real pain to put together but over time with user contributions, it could become quite comprehensive.
Similarly it should be possible to automate the #pragma comment(lib... statements Pelle and I added for version 2.9 ... since we are going to transform the libs we can just as easily build a database of which imports are in which lib and correlate that against headers, automatically inserting the pragmas to maintain this very nice functionality.
I'm willing to help where I can... but being mostly an applications guy, this is just on the edge of what I know how to do.
-
Can't you least try separated WSDK environment for testing ?
After that tell us those problems.
Frankie made good work for that already.
-
Can't you least try separated WSDK environment for testing ?
After that tell us those problems.
Frankie made good work for that already.
Of course. As I find stuff I will let you know.
But, as I said, the goal is to build some kind of comprehensive documentation.
-
These folders are in my WSDK test:
C:\code1\PellesC
├───bin
│ ├───AddIns
│ ├───AddIns64
│ ├───Help
│ └───Intl
├───include
│ └───Win
│ └───gl
└───lib
├───Win
└───Win64in bin foldercformat.dll
cformat64.dll
idespawn.exe
idespawn64.exe
pobr.dll
pobr.exe
pobr64.dll
pocc.exe
poide.exe
poide64.exe
polib.exe
polink.exe
pomake.exe
porc.dll
porc.exe
porc64.dll
porc64.exe
sqlite3.dll
sqlite364.dll
support.dll
support64.dll
sysdefs.tagin bin\Intl folderrsrc0009.dllStart with that and use poide -x -xml option
-
For me is clear that the headers packed in the PellesC distribution are there just to install a ready to run compiler suite.
Hense my oft repeated suggestion that we should treat the Windows API part of the project as a mere starting point, not as a final be all and end all. There is a LOT of stuff missing... COM, DShow, DirectX and more.
Infact the SDK's could not be redistribuited, and downloading an SDK install it and use is not so simple to explain to first time users. That's why Pelle make the decision to include a subset of headers, that IMHO are still enough unless you need a very advanced library or feature :P
Well, not so advanced. For example: It's not possible to write a Media Player in Pelles C without resorting to MCI which will eventually be removed by MS.
But the point is, considering that Pelle should know that his compiler suite could use MS headers, he has not made public the feature for at least the advanced users... :o
And more importantly, he knows what has to be done to convert the API for compatibility with his compiler and this information is not available anywhere.
BUT... and this is crucial... What we should really should want to do is use Pelles CRT and extension libs with the Windows API headers. We should see his distribution of Pelles C as one thing and the Windows API headers and libs as something separate. It's not enough to get it working with all MS headers including their CRT... we actually do need to convert the headers to work with Pelles CRT as we go. This might mean changing some variable types, modifying typedefs and so on. It's not a simple matter of changing folders in the project settings.
I have also copied new libraries in the lib folder and they works OK, unless the uuid.lib that triggers a linker error for an 'unknown codeview symbol 0x00). No problem compiling without debug information. Unless you don't need a very recent UUID you can still use the original library when compiling debuggable executables.
The best bet here is to take all the SDK libs and remove debugging code. As it is now, we can't debug track into any of the libs as it is... so this would not be a loss. It would however give us access to new imports in those libs that are not in Pelles libs.
Last, to all PellesC users, I don't understand why nobody give any feedback. Is this issue of any interest only for me and Timo? :-\
Nope... I'm betting this is a matter of concern for every last one of us. Who doesn't want a complete set of Windows API headers and libs?
The big bugaboo with this right now is that most people are probably sitting back waiting to see how badly this fails before getting involved... and of course that is what will cause the ultimate failure.
I'm here now and I will help you any way I can but as I've already noted, some of this stuff is clearly beyond my current skills... But I will help as much as I can.
-
These folders are in my WSDK test:
Start with that and use poide -x -xml option
Sounds like a plan. I have the 7.0 sdk headers and libs in a zip file (BIG zip file) so it's no problem for me to put them wherever they're needed.
I have a couple of quick service calls to run this afternoon but this evening I will begin testing...
And for everyone else ... the more the merrier. Lets get this done!
-
For those who still don't know that it is possible to run several versions of PellesC in same machine with commandline options -x -xml.
Just try to do same with Microsoft Visual Studio with /useenv and have some fun (wet day dreams)?
I have PellesC versions 2.50 - 7.0 for testing in same machine.
Versions before 5 must handle register between sessions.
Just ask details to do that.
EDIT: create empty sysdefs.tag to PellesC\bin folder for new headers.
-
As promised I've started working in earnest on this problem of getting the SDK headers and libs to work in PellesC. The first step is to create a test bed...
I took a nice empty flash drive and installed a copy of Pelles C x64 on it without the "Windows Development" option so that I had only the tools and CRT... no API headers or libs.
Thanks to the heads up from Timo, I got it working independently of the main copy on my hard disk by using the -X and -XML settings.xml options.
Next I installed the Windows SDK version 7.1 and selected only the Windows API headers and libs. These I copied to the flash drive in a folder named WinAPI (of course).
Finally I made a backup of the whole thing, since I am going to mess with it horridly...
This produced a tree like this....
L:.
├───backup
│ ├───PellesC
│ │ ├───Bin
│ │ │ ├───AddIns64
│ │ │ ├───Help
│ │ │ ├───Intl
│ │ │ └───Wizards64
│ │ ├───Include
│ │ │ └───sys
│ │ └───Lib
│ │ ├───Win
│ │ └───Win64
│ └───WinApi
│ ├───Include
│ │ └───gl
│ ├───Lib32
│ └───Lib64
├───PellesC
│ ├───Bin
│ │ ├───AddIns64
│ │ ├───Help
│ │ ├───Intl
│ │ └───Wizards64
│ ├───Include
│ │ └───sys
│ └───Lib
│ ├───Win
│ └───Win64
├───Projects
│ ├───hello_sdk
│ │ └───output
│ ├───make_all_hdr
│ │ └───output
│ └───Ms-Headers
└───WinApi
├───Include
│ └───gl
├───Lib32
└───Lib64
The most obvious way to test this is to write some silly little project and include all 1800+ headers...
(I'm not worried about the libs yet)
So now I needed some way to make a list of all the .h files in the \winapi\include folder. For this I did a quick and dirty project called Make_All_Hdr (project attached) which read the include folder and wrote a header file listing all the .h files. This drops a file named AllHeaders.h into the flash drive's root folder (copy attached). I then moved it to the \WinAPI folder.
Ok so now I've got a header that includes all headers... crash dummy level coding!
Next I wrote a quicky Hello World program (project attached) set the project folders to point to the WinApi\Include and WinApi\Lib32 folders on the flash drive and let her rip...The goal is to get it to compile without errors or warnings with all those headers included.
By the way when you run this, stand back... it's pretty amazing!
Ok, so now I have a test bed...
-
Hi Tater Welcome back :D
I'm happy to see you back here, and to see a voluteer that starts to do... ;D
While I don't agree on some points, easy to speak of and almost impraticable, I see many good points. The most valuable is to strip off debugging informations from libraries that are in the new MS formats and alien tol PellesC.
For me is clear that the headers packed in the PellesC distribution are there just to install a ready to run compiler suite.
Infact the SDK's could not be redistribuited, and downloading an SDK install it and use is not so simple to explain to first time users. That's why Pelle make the decision to include a subset of headers, that IMHO are still enough unless you need a very advanced library or feature :P
Well, not so advanced. For example: It's not possible to write a Media Player in Pelles C without resorting to MCI which will eventually be removed by MS.
But the point is, considering that Pelle should know that his compiler suite could use MS headers, he has not made public the feature for at least the advanced users... :o
And more importantly, he knows what has to be done to convert the API for compatibility with his compiler and this information is not available anywhere.
The SDK is not distributable by legal issue, the use license from MS clearly specify this. For a novice to install separate headers would be not an easy job so many many potential users will renounce to PellesC as a C programming training tool.
If you program something enough advanced you should be able to deal with advanced issues, so I don't see the point.
The fact that PellesC works happily with untouched MS headers contraddict the point that it requires twickings to make headers compatible with PellesC compiler and reinforces my affirmation above.
BUT... and this is crucial... What we should really should want to do is use Pelles CRT and extension libs with the Windows API headers. We should see his distribution of Pelles C as one thing and the Windows API headers and libs as something separate. It's not enough to get it working with all MS headers including their CRT... we actually do need to convert the headers to work with Pelles CRT as we go. This might mean changing some variable types, modifying typedefs and so on. It's not a simple matter of changing folders in the project settings.
The compiler itself is not implied in how subsystems and libraries works, the C language compilers works for almost whole systems existing on the earth just changing definitions (headers) and libraries (if it generates code for the right CPU of course ).
The issue in the MS world is that Ms added a lot of stuff not C-standard compliant, and on this PElle made an excellent work adding almost all of them (infact the system compiles executables with MS headers and libraries). But PellesC is also a strict C99, C11 compliant which is divergent from MSVC, so the CRT mainly will have problems (why don't use the free MSVC to compile is this case? )
The big bugaboo with this right now is that most people are probably sitting back waiting to see how badly this fails before getting involved... and of course that is what will cause the ultimate failure.
Very nice ... ;D
Why should we waste time then? It works for me and I was able to do it, but while it took me a couple of hours to make it work, I had to spend much more time to write documentation and support, that was a kind of due to share the work with others after I have made public the first step ... :P
Ok so now I've got a header that includes all headers... crash dummy level coding!
Next I wrote a quicky Hello World program (project attached) set the project folders to point to the WinApi\Include and WinApi\Lib32 folders on the flash drive and let her rip...The goal is to get it to compile without errors or warnings with all those headers included.
By the way when you run this, stand back... it's pretty amazing!
Ok, so now I have a test bed...
You cannot simply include all headers, many of them are C++ only (as gdiplus.h) and other specialized for object programming embedded in the MSVC compilers. You will never ever can put all MS headers in a plain C compiler (PellesC or whatever...)
-
wincodec.h needs fixing ?
intsafe.h(8546): error #1050: Redefinition of macro 'LOWORD'.
intsafe.h(8547): error #1050: Redefinition of macro 'HIWORD'.
-
The SDK is not distributable by legal issue, the use license from MS clearly specify this. For a novice to install separate headers would be not an easy job so many many potential users will renounce to PellesC as a C programming training tool.
Yet, oddly enough that's what's happening right now.
Based on experience in other forums, here's how it goes for most people... They will get curious about programming and will go out on the net looking for a free "thingy" to experiment with and will find Pelles C. Many will download a book or a string of tutorials and do some console mode programming (still the best way to learn). Then one of two things happens; either they give up or they hit the limits of Pelles C and they will end up with Visual Studio Express or one of the many MinGW implementations... at that point we lose them.
But we do more than simply losing them... because of the limitations of free VC++ and MinGW setups (No IDE, no resource tools, etc) they will usually end up using WxWidgets, QT or some other massively bloated library that ultimately produces really terrible software. The whole industry looses.
If you program something enough advanced you should be able to deal with advanced issues, so I don't see the point.
Ok, lets try this on for size... Some time ago, before coming to Pelles C, I wrote a very comprehensive Inventory Control program in Turbo Pascal. I wrote a custom data base, all the user interfaces, automated tasks such as purchasing and invoicing and even included self-maintenance. When Borland ditched Pascal for Delphi, my project --by then a wage earner-- was orphaned. So I took the decision to rewrite in Pelles C and convert it to a multi-tasking Windows program at the same time. Nearly half a million lines of code, no small challenge, to be sure. The package has since been sold to another programmer (for a very nice lump of change, I might add) who is now working feverishly to convert it to MinGW.
I would say that qualifies me as sufficiently advanced. In all that, I've tried over and over again to get the MS Headers and Libs working with Pelles C... and it ain't happening.
The fact that PellesC works happily with untouched MS headers contraddict the point that it requires twickings to make headers compatible with PellesC compiler and reinforces my affirmation above.
Pelles C does not work happily with untouched MS headers. That you can compile some little program using a couple of headers and a message box with the Windows.h header does not imply anything other than the Windows.h header contains nothing that needs conversion... that you got lucky.
Try this in a serious project like a media player or desktop enhancement where you need COM objects or try writing your own IDE. You will very rapidly hit the wall... Yet, I can use C-99 standards with TDM-GCC and write these things easily enough... Because the headers are converted to work with that compiler.
Pelles C is most decidedly a beginners tool, always has been.
Duplicate my test bed... start working through the errors... you will find that most headers need massive changes including redefinition of variable types, inclusion of CRT headers and so on to work. If POCC didn't stop at 100 errors, my little test bed would produce tens of thousands of errors.
Why should we waste time then? It works for me and I was able to do it, but while it took me a couple of hours to make it work, I had to spend much more time to write documentation and support, that was a kind of due to share the work with others after I have made public the first step ... :P
Perhaps one rason to waste the time is that at the end of it everybody, including you ends up with a far better compiler/library and API.
You cannot simply include all headers, many of them are C++ only (as gdiplus.h) and other specialized for object programming embedded in the MSVC compilers. You will never ever can put all MS headers in a plain C compiler (PellesC or whatever...)
But you said we can... You've been insisting that Pelles C works with untouched headers...
I proved it does not.
The question is... what to do about it.
-
It seems to be normal :(
MS headers have alot of this, just google "windef.h redefinition of hiword".
On MS compiler a macro redefinition is just a warning, so MS, and the users, don't care much about it >:(
Anyway to fix:
#define LOWORD(_dw) ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#define HIWORD(_dw) ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
Simply add:
#ifndef LOWORD
#define LOWORD(_dw) ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#endif
#ifndef HIWORD
#define HIWORD(_dw) ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
#endif
Or... comment them out 8)
-
You cannot simply include all headers, many of them are C++ only (as gdiplus.h) and other specialized for object programming embedded in the MSVC compilers. You will never ever can put all MS headers in a plain C compiler (PellesC or whatever...)
Ok... so how about we start by making a list of headers that cannot be converted.
-
It seems to be normal :(
MS headers have alot of this, just google "windef.h redefinition of hiword".
On MS compiler a macro redefinition is just a warning, so MS, and the users, don't care much about it >:(
Anyway to fix:
#define LOWORD(_dw) ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#define HIWORD(_dw) ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
Simply add:
#ifndef LOWORD
#define LOWORD(_dw) ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#endif
#ifndef HIWORD
#define HIWORD(_dw) ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
#endif
Or... comment them out 8)
See... you're already modifying headers... BUT, where is the documentation on this, how do we know what to modify in each header for correct behaviour?
Some of Pelles headers have not been updated since Win2000. There are entire blocks of functionality missing (COM, being the most glaring omission), apparently there are now a number of headers that cannot be converted...
If Pelles is going to claim compatibility, at the very least he should be documenting the incompatibilities...
-
Dear Tater,
I really don't understand the point :o
Let resume:
Nobody contested your experience (I'm not interested to make public the mine) but let say we are both skilled ;D
We (not only me, but who cooperated in this thread) find a solution.
All my projects work with no problems.
I wrote down the howto, but you moved in a differnt way, made a cauldron of headers, made for a C/C++ compiler, and expected that they works together? :o
Have you tryied to compile something following the instructions?
Duplicate my test bed... start working through the errors... you will find that most headers need massive changes including redefinition of variable types, inclusion of CRT headers and so on to work. If POCC didn't stop at 100 errors, my little test bed would produce tens of thousands of errors.
Duplicate us test bed and check it works? ;D
Pelles C does not work happily with untouched MS headers. That you can compile some little program using a couple of headers and a message box with the Windows.h header does not imply anything other than the Windows.h header contains nothing that needs conversion... that you got lucky.
:o :o :o :o :o :o
What means? You were unlucky? I'm just lucky????? I close my eyes and write technical answers by pounching the keyboard in hope that words having any sense come out????? :o :o :o :o :o
But you said we can... You've been insisting that Pelles C works with untouched headers...
But at least to be aware of what you are including???? ;)
You are free to follow a different way, to have a different mind ;D We are in a free world (at least our countries are supposed to be so), but the respect is the the base of any interpersonal relation.
As I said what I have done is enough for me, I will give help to solve problems that can come out, but don't see any more development necessary.
If you will define a different strategy that shows something working I will be honoured to partecipate to the development 8)
Bring me up Scotty I will give all the help.
See... you're already modifying headers... BUT, where is the documentation on this, how do we know what to modify in each header for correct behaviour?
Is where I have found it on the net, try googling.... ::)
As last consideration doesn't seem to you that you are getting a little bit .... trollish... ::) it seems LD Blake words ;D
I'm jocking of course. ;D
-
Dear Tater,
I really don't understand the point :o
I'd say that's getting rather obvious.
Let resume:
Nobody contested your experience (I'm not interested to make public the mine) but let say we are both skilled ;D
We (not only me, but who cooperated in this thread) find a solution.
All my projects work with no problems.
But what are your Pelles C projects? IIRC, you once told us that for anything "serious" you use Delphi. So I'm going to take a guess that you use Pelles like most people do... quick jobs, support dlls and the occasional console program.
Yes it is likely you can either use as-is or easily convert quite a few of the headers for such simple tasks... For example, if I have a small GUI project that needs only Windows.h and maybe Commcrtl.h I can convert those headers in minutes... In fact I've done several on my own.
However; when things get serious --like in a big project-- the only smart answer is to head for a different compiler because you're either going to hit the limits of Pelles C or you're going to find yourself in this quagmire of converting headers with little or no documentation.
Now, let me be perfectly plain about this... here's my cards on the table...
With the exception of a stack management issue I idetified last year...
http://forum.pellesc.de/index.php?topic=5077.0 (http://forum.pellesc.de/index.php?topic=5077.0)
... I happen to think that Pelles C, and POIDE are the bees knees. There is no better compiler and IDE on the net at any price. I like Pelles C I really do.
However; with the Windows API being omissive and now becomming outdated, I find myself struggling to do stuff that should be "advanced" but possible. COM is one example but there are several others.
My suggestion here is that we (including Pelle) do one of three things:
- Admit and publish the limitations of the package. (which is happening now)
- Get busy and fill out the missing functionality.
- Let Pelles C die a rather ugly and uncermonious death.
Personally I'm favouring #2 since I would like to continue working in plain C but with the fullness of the Windows API.
Most of the Object Oriented headers (COM, DirectX, etc) from MS include C compatible interfaces in their bodies. (GDIPLUS being a noteworthy exception) It should thus be possible to use them with Pelles C... but there is some unknown thing that is preventing this. It seems that no matter what I do I can't get them to work... and the question is "Why?"... what aren't we being told?
If that documentation were here on the forums, in some comprehensive form, I would be more than happy to do the conversions and upload the new headers and libs... no problem.
Instead we've got you and timo --both better programmers than I-- talking over our heads and saying you know how to do it so it should not be a problem... But if an individual does not know how to do it, no amount of telling us it can be done is going to help.
I wrote down the howto, but you moved in a differnt way, made a cauldron of headers, made for a C/C++ compiler, and expected that they works together? :o
My test bed is a starting point from which to build a catalogue of which headers can and cannot be converted, and what changes are needed to make them work. I don't claim it solves the problem, it is merely a tool for examining the problem.
Have you tryied to compile something following the instructions?
Yes... I did. It will compile a few simple things like my little backup program or my file integrity scanner... but when unleashed on anything of even moderate complexity like my HTPC remote control or build script tool it falls flat on it's face.
It works with the headers you used... but that is not a general purpose improvement, it's a very specific example.
But you said we can... You've been insisting that Pelles C works with untouched headers...
But at least to be aware of what you are including? ??? ;)
Right... as I said the first step is to compile a list of headers and libs that cannot be converted because they are for C++ or C# or whatever... We then eliminate them from my mass include and carry on...
The goal is not to find some example to prove it works... the goal is to fix all the things that prevent it from working.
As I said what I have done is enough for me, I will give help to solve problems that can come out, but don't see any more development necessary.
So you've made some minor contribution and now you think it's all over and done with?
Thanks.
If you will define a different strategy that shows something working I will be honoured to partecipate to the development 8)
Does it not occur to you that it is just as important to know what does not work?
We know you can't just switch the project folders and go for it... that is 100% painfully obvious... so we start by making a list of what does not work and then figuring out how to fix it.
Showing that some small subset does work accomplishes absolutely nothing.
As last consideration doesn't seem to you that you are getting a little bit .... trollish... ::) it seems LD Blake words ;D
I'm jocking of course. ;D
Yes, I am being assertive. Ever since version 2.90 I've been pressing gently for better Windows API support, either by adding more stuff to the basic distribution or by converting MS headers after the fact... so far all I've seen is a bunch of trivial examples of something that does work. That's not problem solving... that's showing off.
-
Dear Tater,
I'm travelling and couldn't answer more up to tomorrow.
But I would clarify some points (I will not quote things).
I like unlucky people like me need to work to live, so unfortunately I don't have so much time as required by a so huge job like the one you are proposing.
PellesC is a plain C standard compliant compiler, and many things simply cannot be done with it (because are not std compliant or because are not plain C). Yes there will be tricky ways, but they will never be orghanic hackings. If you need that particular features you have to switch to MSVC.
Why you always point out your competence? Nobody want to diminuish you, why you put on the defense?
You always ask for documentation and for more explanation on how to do it, it's a no sense, I don't know how to do it. Give me a problem and I'll try to solve it.
I'm not better than you, but with a different experience. I worked a lot inside the OS's than outside. I'm sure that you can write more faster, and much better, than me a complex GUI application (by the way I don't use Delphi, while I used a lot of languages, Delphi is not in my software, maybe you confused me with someone else).
If you tryied to write a code that uses headers that creates problem could you post a small project so we all together could take a look at it and maybe found a general solution that solves also other problems?
Last, please don't be hungry with Pelle and its tool. Pelle wrote it, a little bit for fun and a little bit for utility, to sell for special applications that requires standard compliance. And made a very good job, but is his compiler, and he has the last word on how it must work. He also decided to donate free usage to anybody asking in change only voluntarily contribution and help to test it.
-
But I would clarify some points (I will not quote things).
I like unlucky people like me need to work to live, so unfortunately I don't have so much time as required by a so huge job like the one you are proposing.
There seem to be a couple of choices here... One guy working alone puts in 1,000 hours on this or 100 people working together each put in 10 hours. Nobody is saying YOU have to do this... In fact, I'm answering your appeal for help and cooperation.
PellesC is a plain C standard compliant compiler, and many things simply cannot be done with it (because are not std compliant or because are not plain C).
Yes I know that... but there is more that can be done than is included in the standard distribution.
Yes there will be tricky ways, but they will never be orghanic hackings. If you need that particular features you have to switch to MSVC.
Ok, thanks for the help, see you around... >:(
Why you always point out your competence? Nobody want to diminuish you, why you put on the defense?
You and I know what we can do but we are not the only two people reading this. Someone who's contemplating jumping to this as a project should have some idea of the skills of the other members, don't you think?
You always ask for documentation and for more explanation on how to do it, it's a no sense, I don't know how to do it. Give me a problem and I'll try to solve it.
Ok... so none of us knows how to do it... Does that not strike you as a good time to ask for instructions?
I'm not better than you, but with a different experience. I worked a lot inside the OS's than outside. I'm sure that you can write more faster, and much better, than me a complex GUI application.
I doubt it... I've always respected your skills and whether you know it or not you've helped me quite a bit over the years.
If you tryied to write a code that uses headers that creates problem could you post a small project so we all together could take a look at it and maybe found a general solution that solves also other problems?
OK... when I take my test bed and modify the Hello_SDK program like this...
// hello world to test sdk headers
// set project folders to SDK folders
#include <stdio.h>
//#include "\WinAPI\AllHeaders.h"
#include <windows.h>
int _cdecl main(void)
{
puts("Hello SDK User!\n");
return 0;
}
... so it includes only Windows.h
I get the following error cascade...
Building main.obj.
L:\WinApi\Include\winnt.h(1202): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(12880): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(13305): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2935): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2938): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2941): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3053): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3056): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3059): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3062): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winuser.h(3181): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1242): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1256): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\shellapi.h(666): warning #1063: Single-line comment contains escaped new-line.
L:\WinApi\Include\objbase.h(865): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\stralign.h(113): warning #2018: Undeclared function 'wcscpy'; assuming 'extern' returning 'int'.
L:\WinApi\Include\stralign.h(113): error #2060: Invalid return type; expected 'wchar_t *' but found 'int'. *** Error code: 1 ***
Done.
I've been chasing these warnings and the final error all morning without much success...
It is NOT obvious how the Invalid token is being produced... But I'm guessing it's a point source error since it is so frequent... any idea where? any idea how to fix it?
Last, please don't be hungry with Pelle and its tool. Pelle wrote it, a little bit for fun and a little bit for utility, to sell for special applications that requires standard compliance. And made a very good job, but is his compiler, and he has the last word on how it must work. He also decided to donate free usage to anybody asking in change only voluntarily contribution and help to test it.
Sigh... I know all that...
But, for a minute, look at the activity on other forums --the D forum is a good example-- and see the users working out issues, contributing new stuff, expanding the project... Why is it wrong to do that here?
Seriously... If Pelle wants to tell me to "leave it alone", I will. I'll do what you say and switch myself over to a different compiler... but only an idiot would tell contributing users to piss off. Pelle's genius should be complimented by people seeking to add or improve things...
-
Is there no one who wants to help out with this?
The goal is to fill out the Windows API for Pelles C... is that not worth a little time?
-
MS-Headers.lst, some c++ headers removed.
MS should start fixing their headers too, xenroll.h#ifdef __cplusplus
class DECLSPEC_UUID("43F8F289-7A20-11D0-8F06-00C04FC295E1")
CEnroll;
#endif
#endif /* __XENROLLLib_LIBRARY_DEFINED__ */
/* interface __MIDL_itf_xenroll_0000_0007 */
/* [local] */
extern "C" IEnroll * WINAPI PIEnrollGetNoCOM(void);
extern "C" IEnroll2 * WINAPI PIEnroll2GetNoCOM(void);
extern "C" IEnroll4 * WINAPI PIEnroll4GetNoCOM(void);
-
... so it includes only Windows.h
I get the following error cascade...
Building main.obj.
L:\WinApi\Include\winnt.h(1202): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(12880): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(13305): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2935): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2938): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2941): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3053): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3056): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3059): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3062): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winuser.h(3181): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1242): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1256): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\shellapi.h(666): warning #1063: Single-line comment contains escaped new-line.
L:\WinApi\Include\objbase.h(865): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\stralign.h(113): warning #2018: Undeclared function 'wcscpy'; assuming 'extern' returning 'int'.
L:\WinApi\Include\stralign.h(113): error #2060: Invalid return type; expected 'wchar_t *' but found 'int'. *** Error code: 1 ***
Done.
I've been chasing these warnings and the final error all morning without much success...
It is NOT obvious how the Invalid token is being produced... But I'm guessing it's a point source error since it is so frequent... any idea where? any idea how to fix it?
Hi Tater,
but have you read this (http://forum.pellesc.de/index.php?topic=6109.msg22344#msg22344)?
Sure? ;)
-
MS-Headers.lst, some c++ headers removed.
Thanks Timo Good job.
I have updated the tool with your list.
If you have time, and are happy with it maybe can add to the tool a small text substitution routine for the small fixing we have found. Seems that the notes about the patches are not very clear.
MS should start fixing their headers too
Yes ;) You're right :D
I have update the instructions adding the fixing for 'Xenroll.h' (point 11), and killed the warning for __declspec(selectany) (point 12) by defining it as nothing (selectany make sense generally only for C++ that can duplicate constructors and destructors more than one time).
-
Hi Tater,
but have you read this (http://forum.pellesc.de/index.php?topic=6109.msg22344#msg22344)?
Sure? ;)
Yes I read it ... No one does not fix problems by ignoring them.
Turning off the warning is not the way to do this... eventually you will have turned off enough warnings that you will find yourself in a situation where a warning that should have been heeded is not delivered.
-
I agree with Tater, to do the job properly is huge task - I've messed with various MS headers in the past and this one is one that I hesitate to start (getting old, brain power is decreasing). Ideally an automated process is needed especially for beginners, plus, as new headers are added the automated process would hopefully deal with the additions.
John
-
SDK Error list to check.
Many errors was caused by missing header before or wrong order to include.
Most error are just by redeclaration.
-
Great to see you back Tater.
Long live our forum (upstart) member in his current (but former) incarnation !
Welcome back home.
Ed
-
I have updated the tool with your list.
What tool do you mean?
-
This tool at here (http://forum.pellesc.de/index.php?topic=6136.msg22344#msg22344)
Better to start with copy of PellesC and use -x -xml options.
This tool is for experiment for header fix here (http://forum.pellesc.de/index.php?topic=6109.msg22346#msg22346)
I've messed with various MS headers in the past and this one is one that I hesitate to start (getting old, brain power is decreasing).
Welcome to group ;)
What part are you interested ?
-
Great to see you back Tater.
Long live our forum (upstart) member in his current (but former) incarnation !
Welcome back home.
Thanks, we'll see how long my welcome lasts....
-
I agree with Tater, to do the job properly is huge task - I've messed with various MS headers in the past and this one is one that I hesitate to start (getting old, brain power is decreasing). Ideally an automated process is needed especially for beginners, plus, as new headers are added the automated process would hopefully deal with the additions.
Absolutely we need to automate the process...
We're talking about 1800+ headers. Granted some will be eliminated as being C++ with no C Interfaces...
But I'm guessing we're still talking about more than 1000 headers.
Moreover it is not enough to simply hack the headers. We're going to have to modify/rebuild all the libs too. We have no idea how many missing imports (linker errors) we will run into if we don't also rework the Libs.
What neither Ralph nor Timo seem to appreciate is that over 500 new functions have been added to the API since Win2000 when the current headers were first created. Nobody actually knows how many are not present in the current Pelles C API.
By piecing the header set into my test bed in blocks of 10 headers I've already counted more than 15,000 errors and warnings... and ... I'm only half way through the process. Granted a lot of these are the same error over and over again, but at this point we have no clue either what's causing them or how to fix them.
One thing I do know for absolute certain.... disabling compiler warnings is NOT the way to do it.
When preparing the original set for Pelles C, Pelle would have had some pretty good idea what the incompatibilities were and how to fix at least most of them. However; none of this is documented anywhere so we're having to learn this as we go.
Take any header for an example. Compare Pelle's version to the SDK version. In most cases these headers are more than slightly different. Defines have been changed, the order of things is different, stuff has been added, stuff has been taken out... It would be enormously helpful to know what and why... Simple things like "We can't do LPCWCHAR so change it to wchar_t*" would make a huge difference in the depth of the effort.
Frankies tool is basically a copier... that isn't even necessary since we can just point our project options at the SDK headers, no matter where they are. What is needed is a *translator*... Perhaps working from a Rules file telling it what do do in each header. With that level of automation, it should be possible to do a transformation that works.
Then we have the problem of what to do with the Libs...
-
timovjl,
>>Welcome to group ;)
:)
>>What part are you interested ?
Are you asking about my old brain? ;)
John
-
Least i do something to help others ;)
Yep, that was very helpful, thank you.
-
SDK Error list to check.
Hi Timo,
Can't help much with this as C is not my area of expertise, but I've sorted your list to highlight the repetitive errors, see attachment.
Apparently Pelles C can't read certain things correctly. Since we can't change the compiler, this implies that Pelles C will need a modified copy of the headers. Some errors seem to occur only when using Pelles C headers in parallel, i.e. that "previously defined" stuff.
Perhaps one could use your file and add, for each error, the error line in the header plus the following line; so that you could see if there is a problem that can be automatically fixed during translation.
-
Just so everyone knows....
I am going to be offline for a few days, probably till Tuesday, reconfiguring my systems.
I'll rejoin the conversation when I can.
-
frankie,
I used your MS-Headers-1.11, it made a backup folder but did not copy the files from the SDK folder to the PellesC folder so I copied them manually.
Your MS-Headers-1.11 compiled ok so I tried my FindFile project. Here are the errors for the file FindFile.c.
====================
Building FindFile.obj.
B:\PellesC\Include\Win\winnt.h(898): warning #2195: Unrecognized intrinsic function: '_rotl8'.
B:\PellesC\Include\Win\winnt.h(899): warning #2195: Unrecognized intrinsic function: '_rotl16'.
B:\PellesC\Include\Win\winnt.h(900): warning #2195: Unrecognized intrinsic function: '_rotr8'.
B:\PellesC\Include\Win\winnt.h(901): warning #2195: Unrecognized intrinsic function: '_rotr16'.
B:\PellesC\Include\Win\winnt.h(2609): warning #2195: Unrecognized intrinsic function: '_InterlockedIncrement16'.
B:\PellesC\Include\Win\winnt.h(2610): warning #2195: Unrecognized intrinsic function: '_InterlockedDecrement16'.
B:\PellesC\Include\Win\winnt.h(2611): warning #2195: Unrecognized intrinsic function: '_InterlockedCompareExchange16'.
B:\PellesC\Include\Win\winnt.h(2612): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winnt.h(2613): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winnt.h(2614): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winnt.h(2620): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winnt.h(2621): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winnt.h(2622): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
B:\PellesC\Include\Win\winnt.h(2703): warning #2195: Unrecognized intrinsic function: '_ReadWriteBarrier'.
B:\PellesC\Include\Win\winnt.h(2759): warning #2195: Unrecognized intrinsic function: '__faststorefence'.
B:\PellesC\Include\Win\winnt.h(2765): warning #2195: Unrecognized intrinsic function: '_m_prefetchw'.
B:\PellesC\Include\Win\winnt.h(2811): warning #2195: Unrecognized intrinsic function: '__int2c'.
B:\PellesC\Include\Win\winnt.h(2835): warning #2195: Unrecognized intrinsic function: '__getcallerseflags'.
B:\PellesC\Include\Win\winnt.h(2848): warning #2195: Unrecognized intrinsic function: '__segmentlimit'.
B:\PellesC\Include\Win\winnt.h(2861): warning #2195: Unrecognized intrinsic function: '__readpmc'.
B:\PellesC\Include\Win\winnt.h(2969): warning #2195: Unrecognized intrinsic function: '__mulh'.
B:\PellesC\Include\Win\winnt.h(2970): warning #2195: Unrecognized intrinsic function: '__umulh'.
B:\PellesC\Include\Win\winnt.h(2993): warning #2195: Unrecognized intrinsic function: '__shiftleft128'.
B:\PellesC\Include\Win\winnt.h(2994): warning #2195: Unrecognized intrinsic function: '__shiftright128'.
B:\PellesC\Include\Win\winnt.h(3009): warning #2195: Unrecognized intrinsic function: '_mul128'.
B:\PellesC\Include\Win\winnt.h(3022): warning #2195: Unrecognized intrinsic function: '_umul128'.
B:\PellesC\Include\Win\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
Done.
==================
Is that what you wanted?
I've only sent the errors for that one file, there are too many errors to include other files from the project.
John
-
Hallo!
There are not many active members in this list. And now there is a big disagreement about this MS-header subject. I am afraid that this big different energies sum to zero.
Why not cook a much smaller portion together?
We could start with an first header file and make some experiences. We could continue with some others and will see how to continue further.
There are two other personal considerations:
- I do not trust automatic conversations in this point.
- I would rather make the MS-header files Pelles C compatible than making Pelles C able to read the MS-headers.
my two cents, czerny
-
Hallo!
There are not many active members in this list.
Hi Czerny yes you're right that's why I moved the instructions on a locked thread to make easier to look the points out of the mess ;)
Why not cook a much smaller portion together?
We could start with an first header file and make some experiences. We could continue with some others and will see how to continue further.
Yes this was the approach I propose, maybe my posts were not clear enough :(
We have to work together nobody can complete this job alone in acceptable times.
I've got a little bit sad that so much energy was waste to discuss ... :'(
There are two other personal considerations:
- I do not trust automatic conversations in this point.
- I would rather make the MS-header files Pelles C compatible than making Pelles C able to read the MS-headers.
my two cents, czerny
Yes we are thinking about this same problem, I have found some problems related to polymorphism of COM headers that lead to multiple functions with the same name. While I have patched them changing in a meaningfull way the name of further occourrencies to automate the process we could not use a simple search and replace (it will locate the code two times unless the search string is very large such to include differentiate code around the patch). Maybe a diff utility could fit better ? :(
-
frankie,
I used your MS-Headers-1.11, it made a backup folder but did not copy the files from the SDK folder to the PellesC folder so I copied them manually.
Your MS-Headers-1.11 compiled ok so I tried my FindFile project. Here are the errors for the file FindFile.c.
.....
Is that what you wanted?
John
Hi John,
yes thanks I'll take a look at errors.
The tool is a fast and dirty job to try to help novice ;) I tested it only on an old XP32 that's all hardware I could access moving around, maybe there is aproblem of protection, maybe you can take a look.
The damned problem with headers is that the most simple way to offer them is to patch-zip-post, but because of licensing it is not possible unless we rewrite them ... :P at this point is more usefull to patch the standard PellesC headers with the missing functionalities! (so we give an help also to Pelle ;) )
Anyway diving ( ;D ) inside headers you'll find that 50% are C++ or nosense, 20% have errors (check on MSDN social), 10% are very specialistics (Native coding, authorization, logon, etc) and the remaining 10% are the headers that we use normally! >:(
John I'll take a fresh copy of your FindFile from your site, have you any idea on a diff tool, or the like apart from SED or AWK, that could help?
-
Hallo!
There are not many active members in this list.
Hi Czerny yes you're right that's why I moved the instructions on a locked thread to make easier to look the points out of the mess ;)
Why not cook a much smaller portion together?
We could start with an first header file and make some experiences. We could continue with some others and will see how to continue further.
Yes this was the approach I propose, maybe my posts were not clear enough :(
We have to work together nobody can complete this job alone in acceptable times.
I've got a little bit sad that so much energy was waste to discuss ... :'(
There are two other personal considerations:
- I do not trust automatic conversations in this point.
- I would rather make the MS-header files Pelles C compatible than making Pelles C able to read the MS-headers.
my two cents, czerny
Yes we are thinking about this same problem, I have found some problems related to polymorphism of COM headers that lead to multiple functions with the same name. While I have patched them changing in a meaningfull way the name of further occourrencies to automate the process we could not use a simple search and replace (it will locate the code two times unless the search string is very large such to include differentiate code around the patch). Maybe a diff utility could fit better ? :(
I would like to have two tables of all the (?) header files of Pelles C and MS with the following infos:
- header file is usable by Pelles C
- header file is up to date
- file needs a C++ Compiler
- header file is a COM interface
- file is in work by [name]
this tables should be available and editable by all of us.
Secondly, there should be a expandable list of typical errors in the MS files
- There are no comment signs '//' after endif, per example.
So every helpers can learn from the experiences of others.
And last but not least. The converted header files should be collected in an downloadable zip-file.
I do not know if this forum software is able to help in one of this points?
What about the wiki?
czerny
-
SDK Error list to check.
Hi Timo,
Can't help much with this as C is not my area of expertise, but I've sorted your list to highlight the repetitive errors, see attachment.
Apparently Pelles C can't read certain things correctly. Since we can't change the compiler, this implies that Pelles C will need a modified copy of the headers. Some errors seem to occur only when using Pelles C headers in parallel, i.e. that "previously defined" stuff.
Perhaps one could use your file and add, for each error, the error line in the header plus the following line; so that you could see if there is a problem that can be automatically fixed during translation.
Hi JJ,
thanks for help, this is really usefull as reference on line numbers if we patch by line number :D
-
WinMerge is a good tool for comparing files / dirs.
John's error list comes from 64-bit version.
I put to PellesC ctype.h this below
#ifdef _MSC_EXTENSIONS
/* for compiling with windows.h -- see Microsoft ctype.h */
#ifdef _WIN64
#pragma warn(disable: 2195)
#endif
change is not in that FixHdrLst here (http://forum.pellesc.de/index.php?topic=6109.msg22346#msg22346)
-
I would like to have two tables of all the (?) header files of Pelles C and MS with the following infos:
- header file is usable by Pelles C
- header file is up to date
- file needs a C++ Compiler
- header file is a COM interface
- file is in work by [name]
Yes one of the scopes of the 'copying' tool was to keep a complete list of files, if open the zip and look inside MS-Headers.lst' you will see that you can comment-out files. With some little more code we can add a comment.
this tables should be available and editable by all of us.
Secondly, there should be a expandable list of typical errors in the MS files
- There are no comment signs '//' after endif, per example.
So every helpers can learn from the experiences of others.
And last but not least. The converted header files should be collected in an downloadable zip-file.
I do not know if this forum software is able to help in one of this points?
What about the wiki?
czerny
The limit is the platform, I don't think the forum support file condivision ...
Maybe it is too early for the wiki ... :-\
-
WinMerge is a good tool for comparing files / dirs.
John's error list comes from 64-bit version.
Yes Timo we can try with WinMerge.
John FindFile can be compiled in its 32 bits version?
-
FindFile can compiled to both versions (64-bit after minor fix).
-
FindFile can compiled to both versions (64-bit after minor fix).
Good to hear! :)
-
Frankie,
>>at this point is more usefull to patch the standard
>>PellesC headers with the missing functionalities!
We could then distribute the headers in a zip.
John
-
Yes one of the scopes of the 'copying' tool was to keep a complete list of files, if open the zip and look inside MS-Headers.lst' you will see that you can comment-out files. With some little more code we can add a comment.
The problem will be that there are as many incarnations of this list as downloaders.
For example, what is the actual file of MS-Headers.lst? This one, included in your tool or that one posted by Timovjl?
czerny
-
Frankie,
>>at this point is more usefull to patch the standard
>>PellesC headers with the missing functionalities!
We could then distribute the headers in a zip.
John
Yes, but it will be much more complicate to define what to add ... :P
Even if IMHO the average of us has never felt the need of something outside of standard PellesC distribution, there is too much stuff inside new SDK's to choose what move and what not.
My original 'hope' was that was possible to produce a kind of preheader with many #defines to use the preprocessor to autofix the MS-headers, but this proven not facible.
The fastest way is to have a compiler that is fully compatible with MSVC, but PellesC is standard compliant and MSVC not ... they could never meet :-\
My first need for something more was the use of COM headers that were not in PellesC, in that case the use of a preheader was working to remove annotation (yes the PRE-Fast technology >:( )
-
The problem will be that there are as many incarnations of this list as downloaders.
For example, what is the actual file of MS-Headers.lst? This one, included in your tool or that one posted by Timovjl?
I have put the last version, that incidentally is the Timo's version, in the attachment of the locked thread.
While we organize better let say that the locked thread is the reference.
-
In my link should be MS-HeaderFix.lst only in FixHdrLst.zip ?
Can anyone figure out why this works with msado15.h / adoint.h ?
...
#define ADOErrors Errors
#define ADOError Error
#define ADOProperties Properties
#define _ADOConnection _Connection
#define _ADORecordset _Recordset
#define _ADOParameters _Parameters
#define _ADOParameter _Parameter
#define ADOParameters Parameters
#define _ADOCommand _Command
#define _ADORecord _Record
#define ADOFields Fields
#define ADOField Field
#define _ADOStream _Stream
#define ADOProperty Property
#include <msado15.h>
...
-
An SVN repository or similar would be the best to allow smooth collaboration in this project.
You have all you need:
- users can lock files they work on, so no two users will work on the same file
- easy update and commit of changes
- etc.
-
Here are old WinMerge.exe and patch.exe.
Example in unified mode:
--- include\Win.SDK\StrAlign.h
+++ include\Win\StrAlign.h
@@ -42,6 +42,7 @@
#if !defined(__STRALIGN_H_) && !defined(MIDL_PASS)
#define __STRALIGN_H_
+#include <wchar.h>
#ifndef _STRALIGN_USE_SECURE_CRT
#if defined(__GOT_SECURE_LIB__) && __GOT_SECURE_LIB__ >= 200402Lpatch.exe -u include\Win\StrAlign.h StrAlign.h.diff
-
Timo what about to use all GNU-Win tools?
We can compile them in source and merge in the tool so it can do anything in one pass: backup the system, copy files and patch them. ;)
Anyway the things changed very fast, a new release of compiler has been deployed, and from I can read many bugs have been removed and more functionalities have been added.
I.e when pelle say
Added #pragma default_convention() to deal with annoying third-party header files.
what is the side effect on MS-headers?
EDIT: That's just for headers that miss the correct calling convention (to avoid to patch all functions call).
Unfortunately I only have an XP-PE32 machine for all my jobs (and don't want take more with me around the world) I can't take a look to the new version not even to documentation (refuses to install on XP).
So I'm considering:
- Is this just a waste of time? Maybe new version doesn't need patching or not made this way...
- All the patches we have found and fixed, showed on the locked thread, have a sense? We are blindly patching headers were the presence of polymorphism clearly shows that that files are intended for C++ (the patches applied permit to use them from plain C ;D, but are the majority of us able to use them?). Will they be of any use? Who tested any program that needs them?
- In the new release Pelle added some more headers maybe they are enough?
- Some patches relative to zero size arrays are plain C class trnslations, while the patches remove the warnings are the structure functional? who take care of verify if they works? There are many ways to patch this kind of declaration is the chosed one the correct one?
Maybe we have to complete the tool and made it working on the base set of headers, then add something else when it use is requested...
-
For someone who just want to just test WSDK with separated copy of PellesC.
make these changes to Pellesc ctype.h
#ifdef _MSC_EXTENSIONS
/* for compiling with windows.h -- see Microsoft ctype.h */
#ifndef _WCHAR_T_DEFINED
#define _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#include <wchar.h>
#endif
#pragma warn(disable: 1058 1063) // <-- add this for MS bugs
#ifdef _WIN64
#pragma warn(disable: 2195) // <-- add this for 64 bit
#endif
#endif /* _MSC_EXTENSIONS */
and copy WSDK headers with frankie's tool and libs manually.
-
I had a look over the new release of PellesC, as far as I can see the project scope is still valid.
The compiler seems to be more logorroic ( :D joke) I got more warnings on already patched files.
I'll go on...
-
Frankie,
Would it not be easier to identify which bits are missing (and worth while) and then add those bits to Pelle's headers.
EDIT: For the PellesC headers that already exist of course.
John
-
WSDK 8
winioctl.h(7277): error #2065: Invalid use of incomplete type 'STORAGE_QUERY_DEPENDENT_VOLUME_LEV1_ENTRY []'.
winioctl.h(7278): error #2065: Invalid use of incomplete type 'STORAGE_QUERY_DEPENDENT_VOLUME_LEV2_ENTRY []'.
winioctl.h(7279): error #2065: Invalid use of incomplete type '(incomplete) union (no name)'.maybe better like thisSTORAGE_QUERY_DEPENDENT_VOLUME_LEV1_ENTRY[1]
STORAGE_QUERY_DEPENDENT_VOLUME_LEV2_ENTRY[1]
-
Frankie,
Would it not be easier to identify which bits are missing (and worth while) and then add those bits to Pelle's headers.
EDIT: For the PellesC headers that already exist of course.
John
John and all I'm sorry, but due to my work duties I have been very busy to update anything, I hope this weekend to produce something.
We planned to integrate in the tool the patch utility, so it will copy and patch file so you should have a fully working set after it run.
Anyway I'm limited on the 64 bits side and need help to test on that side.
Moreover Timo is already looking on the copy problem, John maybe you can also help to discover why the copy fails on some systems and possibly patch the tool (UAC?).
Before to move to add headers to PellesC I would like to have this job finished, so we can use the two headers set for cross-check.
What are your comments?
-
We planned to integrate in the tool the patch utility, so it will copy and patch file so you should have a fully working set after it run.
Ok that sounds good.
Anyway I'm limited on the 64 bits side and need help to test on that side.
Moreover Timo is already looking on the copy problem, John maybe you can also help to discover why the copy fails on some systems and possibly patch the tool (UAC?).
Before to move to add headers to PellesC I would like to have this job finished, so we can use the two headers set for cross-check.
What are your comments?
I will take a look at that copy app and let you know what I find.
Is there something in particular you would like me to look into for 64bit?
EDIT: I apologize - the problem with the copy app was my fault in that my SDK setup was wrong. The Registry entry was not correct.
So, no problem copying the headers.
John
-
Tip for 32-bit user to compile to WIN64.
start ide from patch file SET INCLUDE=C:\code1\PellesC8\include;C:\code1\PellesC8\include\Win
START C:\code1\PellesC8\Bin\poide.exe -x -xml PellesC8.xml
insert into tools menuMenu test: pocc x64
Command: C:\code1\PellesC8\Bin\pocc.exe
Arguments: -Ze -Tamd64-coff $(FilePath)
Use Output tab
-
EDIT: I apologize - the problem with the copy app was my fault in that my SDK setup was wrong. The Registry entry was not correct.
So, no problem copying the headers.
Happy to hear this. :D Anyway the utility allows to manually select folder from and to copy.
Is there something in particular you would like me to look into for 64bit?
Sure could you check if you get only warnings or also errors on sources that you have possibly using less usual headers.
thanks John
-
For those who still don't know that it is possible to run several versions of PellesC in same machine with commandline options -x -xml.
What about the 'sysdef.tag' file in %HOMEPATH%l\Application Data\Pelles C.
-
What about the 'sysdef.tag' file in %HOMEPATH%l\Application Data\Pelles C.
Just create/move sysdef.tag to PellesC\bin folder.
It can be empty one at first start.
-
I'm a little bit tired and some pis..off >:(
There is a big mess between console applications, gui applications allocating a console, threads and whatever you can imagine of.. >:(
The project workspace contains a working copy of patch with many trials to make it work ... not perfectly damn it >:(, but at least in the same way ...
Does anybody understood why the I/O subsystem plays up this way around?
I have reinitialized all local static variables, global variables and the rest. I have reduced to minimum low level I/O, I have simplified it, but the various versions behaves differently from the first run >:(
It seems that PellesC libraries have some problems too.
Anyway if during tests you get messages about existing temporary files just delete them. They are located in the temp directory of your system (usually C:\Documents and Settings\<current user>\Local Settings\Temp).
If someone find the problem or some explanation is welcome ... :(
P.S. The problem is not Patch itself, but when you use it in a gui multithreaded (especially multithreaded) environment, fopen, fclose, _open _close &CO messed up...
I Added the diffs.txt patch file.
-
Well, you've certainly been busy, well done so far!
John
-
Well, you've certainly been busy, well done so far!
John
Thanks John, I was so busy to get really really stupid! ;D
I can't pretend to link a sigle threaded lib with a multithreaded executable! ;D
I waste a lot of time, but didn't noticed it >:(, at last I discovered the problem due to I/O and 'errno' synch between threads. :(
I should be able to post something in short now ... 8)
-
New version 1.21 of the tool.
Now it backups your installation, copy the required files from SDK 7.1 and patches them.
Nice! I'm getting this error whenever windows.h is included.
B:\PellesC\Include\Win\specstrings.h(11): fatal error #1035: Can't find include file <sal.h>.
*** Error code: 1 ***
John
-
sal.h is missing from v 8 ?
-
Thanks for sal.h
64bit
B:\PellesC\Include\Win\winnt.h(898): warning #2195: Unrecognized intrinsic function: '_rotl8'.
B:\PellesC\Include\Win\winnt.h(899): warning #2195: Unrecognized intrinsic function: '_rotl16'.
B:\PellesC\Include\Win\winnt.h(900): warning #2195: Unrecognized intrinsic function: '_rotr8'.
B:\PellesC\Include\Win\winnt.h(901): warning #2195: Unrecognized intrinsic function: '_rotr16'.
B:\PellesC\Include\Win\winnt.h(2609): warning #2195: Unrecognized intrinsic function: '_InterlockedIncrement16'.
B:\PellesC\Include\Win\winnt.h(2610): warning #2195: Unrecognized intrinsic function: '_InterlockedDecrement16'.
B:\PellesC\Include\Win\winnt.h(2611): warning #2195: Unrecognized intrinsic function: '_InterlockedCompareExchange16'.
B:\PellesC\Include\Win\winnt.h(2612): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winnt.h(2613): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winnt.h(2614): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winnt.h(2620): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winnt.h(2621): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winnt.h(2622): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
B:\PellesC\Include\Win\winnt.h(2703): warning #2195: Unrecognized intrinsic function: '_ReadWriteBarrier'.
B:\PellesC\Include\Win\winnt.h(2759): warning #2195: Unrecognized intrinsic function: '__faststorefence'.
B:\PellesC\Include\Win\winnt.h(2765): warning #2195: Unrecognized intrinsic function: '_m_prefetchw'.
B:\PellesC\Include\Win\winnt.h(2811): warning #2195: Unrecognized intrinsic function: '__int2c'.
B:\PellesC\Include\Win\winnt.h(2835): warning #2195: Unrecognized intrinsic function: '__getcallerseflags'.
B:\PellesC\Include\Win\winnt.h(2848): warning #2195: Unrecognized intrinsic function: '__segmentlimit'.
B:\PellesC\Include\Win\winnt.h(2861): warning #2195: Unrecognized intrinsic function: '__readpmc'.
B:\PellesC\Include\Win\winnt.h(2969): warning #2195: Unrecognized intrinsic function: '__mulh'.
B:\PellesC\Include\Win\winnt.h(2970): warning #2195: Unrecognized intrinsic function: '__umulh'.
B:\PellesC\Include\Win\winnt.h(2993): warning #2195: Unrecognized intrinsic function: '__shiftleft128'.
B:\PellesC\Include\Win\winnt.h(2994): warning #2195: Unrecognized intrinsic function: '__shiftright128'.
B:\PellesC\Include\Win\winnt.h(3009): warning #2195: Unrecognized intrinsic function: '_mul128'.
B:\PellesC\Include\Win\winnt.h(3022): warning #2195: Unrecognized intrinsic function: '_umul128'.
B:\PellesC\Include\Win\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
John
-
Nice! I'm getting this error whenever windows.h is included.
B:\PellesC\Include\Win\specstrings.h(11): fatal error #1035: Can't find include file <sal.h>.
*** Error code: 1 ***
John
Hi John,
the header sal.h is in the patch as a file to add (if you look in diffs.txt you'll see it). I have to check why the patch utility doesn't create it. Maybe I missed a switch.
Thanks for the feedback, The cut version that should be added has been posted by Timo. I created it because I can't distribuite something from MS ;D (win sdk doesn't have it!).
64bit
B:\PellesC\Include\Win\winnt.h(898): warning #2195: Unrecognized intrinsic function: '_rotl8'.
B:\PellesC\Include\Win\winnt.h(899): warning #2195: Unrecognized intrinsic function: '_rotl16'.
B:\PellesC\Include\Win\winnt.h(900): warning #2195: Unrecognized intrinsic function: '_rotr8'.
B:\PellesC\Include\Win\winnt.h(901): warning #2195: Unrecognized intrinsic function: '_rotr16'.
...................................
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
John
PellesC doesn't seems to have them :(
I'll modify patch for this also.
-
I modified the patch to be sure that sal.h is created :(
On my system it works, please let me know if there are still problems. Maybe patch utility have still some bugs >:(
For the warnings I'll fix the headers as soon as I'll have time... :P
-
Ok.
I seem to be short of two more headers.
00638 mshtmhst_i.c FAILED
00639 mshtmhst_p.c FAILED
John
-
Ok.
I seem to be short of two more headers.
00638 mshtmhst_i.c FAILED
00639 mshtmhst_p.c FAILED
John
These files definitly are in the list of files to copy (see MS-Headers.lst in the tool zip).
It seems that you have a problem with copy or directories. Could you check please?
Moreover the content of these files is useful fo C++ only, so an empty file should do ... :(
I'll check to be sure that it's so. In this case I'll change the patch to remove the include of these files.
Anyway I don't understand why your system try to include them under plain C .... :( Maybe you can cross-check? :P
-
Ok.
I seem to be short of two more headers.
00638 mshtmhst_i.c FAILED
00639 mshtmhst_p.c FAILED
John
These files definitly are in the list of files to copy (see MS-Headers.lst in the tool zip).
It seems that you have a problem with copy or directories. Could you check please?
Moreover the content of these files is useful fo C++ only, so an empty file should do ... :(
I'll check to be sure that it's so. In this case I'll change the patch to remove the include of these files.
Anyway I don't understand why your system try to include them under plain C .... :( Maybe you can cross-check? :P
Yes they are in the list, that's why your report lists them. Those headers are not anywhere on my drive so I don't understand it.
Anyway, if they are only for C++ remove them.
John
-
Yes they are in the list, that's why your report lists them. Those headers are not anywhere on my drive so I don't understand it.
Anyway, if they are only for C++ remove them.
John
These files are in the SDK-7.1 include. Maybe your SDK installation have some fault? ....
I have not understood if the compiler complains for them or if you just found the error in the copy report.
Before removing them I have to be sure that they aren't included anyway ...
-
Sorry these files aren't for C++ only ... :-[
But seems that they are not used unless "scardssp_i.c" that is included by "ScardSsp.h".
Maybe they could be required when compiling something else?
Edit: They should be necessary when creating the OLE/AUTO object, so for normal compiling should not be required, or there is any other use?? :(
For now I'll not remove them ... :(
-
Ok,
They were listed in your report. The SDK I have is 7.1
John
-
John please can you check if with tool version 1.22 (http://forum.pellesc.de/index.php?topic=6136.msg22344#msg22344) the warnings under X64 disappear?
-
I tried with 1.23 - didn't have any FAILED copied headers this time.
Here are the errors compiling my FindFile app.
Building Dialogs.obj.
B:\PellesC\Include\Win\winnt.h(13074): warning #2018: Undeclared function '__stosb' (did you mean '_stristr'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14948): warning #2018: Undeclared function '__readgsqword' (did you mean '(no name)'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14959): warning #2018: Undeclared function '__readgsqword' (did you mean '(no name)'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
B:\PellesC\Include\Win\stralign.h(475): warning #2018: Undeclared function '_wcsicmp' (did you mean 'uaw_wcsicmp'?); assuming 'extern' returning 'int'.
Building Find.obj.
B:\PellesC\Include\Win\winnt.h(13074): warning #2018: Undeclared function '__stosb' (did you mean '__stoul'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14948): warning #2018: Undeclared function '__readgsqword' (did you mean '__wcstold'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14959): warning #2018: Undeclared function '__readgsqword' (did you mean '__wcstold'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
Building FindFile.obj.
B:\PellesC\Include\Win\winnt.h(13074): warning #2018: Undeclared function '__stosb' (did you mean '__wctob'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14948): warning #2018: Undeclared function '__readgsqword' (did you mean '__wcstold'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14959): warning #2018: Undeclared function '__readgsqword' (did you mean '__wcstold'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
Building FindFileUni64.res.
Building GdipImage.obj.
B:\PellesC\Include\Win\winnt.h(13074): warning #2018: Undeclared function '__stosb' (did you mean '_stristr'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14948): warning #2018: Undeclared function '__readgsqword' (did you mean '(no name)'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14959): warning #2018: Undeclared function '__readgsqword' (did you mean '(no name)'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
B:\PellesC\Include\Win\stralign.h(475): warning #2018: Undeclared function '_wcsicmp' (did you mean 'uaw_wcsicmp'?); assuming 'extern' returning 'int'.
Building IDragDrop.obj.
B:\PellesC\Include\Win\winnt.h(13074): warning #2018: Undeclared function '__stosb' (did you mean '_stristr'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14948): warning #2018: Undeclared function '__readgsqword' (did you mean '(no name)'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winnt.h(14959): warning #2018: Undeclared function '__readgsqword' (did you mean '(no name)'?); assuming 'extern' returning 'int'.
B:\PellesC\Include\Win\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
B:\PellesC\Include\Win\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
B:\PellesC\Include\Win\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
B:\PellesC\Include\Win\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
B:\PellesC\Include\Win\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
B:\PellesC\Include\Win\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
B:\PellesC\Include\Win\stralign.h(475): warning #2018: Undeclared function '_wcsicmp' (did you mean 'uaw_wcsicmp'?); assuming 'extern' returning 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'UINT', previously declared at B:\PellesC\Include\Win\windef.h(173); expected 'unsigned int' but found 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found 'SendMessageW'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ')' but found '('.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'SendMessageW', previously declared at B:\PellesC\Include\Win\winuser.h(3241); expected 'long long int __stdcall function(HWND, unsigned int, unsigned long long int, long long int)' but found 'int __cdecl function()'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found ')'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ')' but found 'integer constant'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2092: Missing identifier.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found 'integer constant'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'WPARAM', previously declared at B:\PellesC\Include\Win\windef.h(183); expected 'unsigned long long int' but found 'int __fastcall function(int)'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'LPARAM', previously declared at B:\PellesC\Include\Win\windef.h(184); expected 'long long int' but found 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found 'integer constant'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1135): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1136): error #2048: Undeclared identifier 'hList' (did you mean 'IACList'?).
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1136): error #2069: Initializer must be constant.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1137): error #2069: Initializer must be constant.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ')' but found '>='.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '>='.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '&&'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '<'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ')' but found '+'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '+'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found ')'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1140): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1141): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1142): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1142): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1143): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1150): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1159): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1178): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1201): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1283): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1344): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1416): error #2051: Cast from 'int' to 'WPARAM' is invalid.
*** Error code: 1 ***
Done.
Build time: 5648ms
John
-
Frankie,
32bit FindFile fares much better but as you can see has problems with IDragDrop.c
Building Dialogs.obj.
Building Find.obj.
Building FindFile.obj.
Building FindFileUni32.res.
Building GdipImage.obj.
Building IDragDrop.obj.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'UINT', previously declared at B:\PellesC\Include\Win\windef.h(173); expected 'unsigned int' but found 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found 'SendMessageW'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ')' but found '('.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'SendMessageW', previously declared at B:\PellesC\Include\Win\winuser.h(3241); expected 'long int __stdcall function(HWND, unsigned int, unsigned int, long int)' but found 'int __cdecl function()'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found ')'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ')' but found 'integer constant'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2092: Missing identifier.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found 'integer constant'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'WPARAM', previously declared at B:\PellesC\Include\Win\windef.h(183); expected 'unsigned int' but found 'int __stdcall function(int)'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2120: Redeclaration of 'LPARAM', previously declared at B:\PellesC\Include\Win\windef.h(184); expected 'long int' but found 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2001: Syntax error: expected ';' but found 'integer constant'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1134): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1135): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1136): error #2048: Undeclared identifier 'hList' (did you mean 'IACList'?).
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1136): error #2069: Initializer must be constant.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1137): error #2069: Initializer must be constant.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ')' but found '>='.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '>='.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '&&'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '<'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ')' but found '+'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found '+'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): warning #2099: Missing type specifier; assuming 'int'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1139): error #2001: Syntax error: expected ';' but found ')'.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1140): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1141): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1142): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1142): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1143): error #2156: Unrecognized declaration.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1150): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1159): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1178): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1201): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1283): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1344): error #2051: Cast from 'int' to 'WPARAM' is invalid.
B:\PellesC\Projects\aProjects22\Findfile\IDragDrop.c(1416): error #2051: Cast from 'int' to 'WPARAM' is invalid.
*** Error code: 1 ***
Done.
Build time: 5336ms
John
-
John,
In IDragDrop.c replace ListView_IsItemVisible to something like JFListView_IsItemVisible and try again. ListView_IsItemVisible is macro in WSDK headers.
-
John,
In IDragDrop.c replace ListView_IsItemVisible to something like JFListView_IsItemVisible and try again. ListView_IsItemVisible is macro in WSDK headers.
That fixed it, well done!
No errors now on the 32bit
John
-
John,
the problem is that in 64bits WinNT.h defines locally all intrinsics that, as stated by standards for C99-C1X, must be in other files defined by the standard itself. >:(
Not a big issue by itself just need to block the redefinition for PellesC, what I have done, and place the inclusion of standard headers (not done yet). This should be an easy job should I have a 64bits machine at hands ... >:(
I asked to Timo to make this modification, as he will give me the list I'll update the tool last time (hopefully :()
-
Ok, look forward to it.
John
-
I loaded the version 1.24 (tested simulating an X64 environment...) :(
-
Using 1.24
Building Dialogs.obj.
B:\PellesC\Include\Win\winbase.h(2122): error #2120: Redeclaration of '_InterlockedIncrement', previously declared at B:\PellesC\Include\intrin.h(210); expected 'long int __cdecl function(volatile long int *)' but found 'long int __fastcall function(volatile long int *)'.
B:\PellesC\Include\Win\winbase.h(2127): error #2120: Redeclaration of '_InterlockedDecrement', previously declared at B:\PellesC\Include\intrin.h(211); expected 'long int __cdecl function(volatile long int *)' but found 'long int __fastcall function(volatile long int *)'.
B:\PellesC\Include\Win\winbase.h(2133): error #2120: Redeclaration of '_InterlockedExchange', previously declared at B:\PellesC\Include\intrin.h(207); expected 'long int __cdecl function(volatile long int *, long int)' but found 'long int __fastcall function(volatile long int *, long int)'.
B:\PellesC\Include\Win\winbase.h(2139): error #2120: Redeclaration of '_InterlockedExchangeAdd', previously declared at B:\PellesC\Include\intrin.h(208); expected 'long int __cdecl function(volatile long int *, long int)' but found 'long int __fastcall function(volatile long int *, long int)'.
B:\PellesC\Include\Win\winbase.h(2146): error #2120: Redeclaration of '_InterlockedCompareExchange', previously declared at B:\PellesC\Include\intrin.h(212); expected 'long int __cdecl function(volatile long int *, long int, long int)' but found 'long int __fastcall function(volatile long int *, long int, long int)'.
B:\PellesC\Include\Win\winbase.h(2153): error #2120: Redeclaration of '_InterlockedCompareExchangePointer', previously declared at B:\PellesC\Include\intrin.h(213); expected 'void * __cdecl function(void * volatile *, void *, void *)' but found 'void * __fastcall function(void * volatile *, void *, void *)'.
B:\PellesC\Include\Win\winbase.h(2159): error #2120: Redeclaration of '_InterlockedExchangePointer', previously declared at B:\PellesC\Include\intrin.h(209); expected 'void * __cdecl function(void * volatile *, void *)' but found 'void * __fastcall function(void * volatile *, void *)'.
B:\PellesC\Include\Win\winbase.h(2182): error #2120: Redeclaration of '_InterlockedIncrement64', previously declared at B:\PellesC\Include\intrin.h(226); expected 'long long int __cdecl function(volatile long long int *)' but found 'long long int __fastcall function(volatile long long int *)'.
B:\PellesC\Include\Win\winbase.h(2187): error #2120: Redeclaration of '_InterlockedDecrement64', previously declared at B:\PellesC\Include\intrin.h(227); expected 'long long int __cdecl function(volatile long long int *)' but found 'long long int __fastcall function(volatile long long int *)'.
B:\PellesC\Include\Win\winbase.h(2193): error #2120: Redeclaration of '_InterlockedExchange64', previously declared at B:\PellesC\Include\intrin.h(224); expected 'long long int __cdecl function(volatile long long int *, long long int)' but found 'long long int __fastcall function(volatile long long int *, long long int)'.
B:\PellesC\Include\Win\winbase.h(2199): error #2120: Redeclaration of '_InterlockedExchangeAdd64', previously declared at B:\PellesC\Include\intrin.h(225); expected 'long long int __cdecl function(volatile long long int *, long long int)' but found 'long long int __fastcall function(volatile long long int *, long long int)'.
B:\PellesC\Include\Win\winbase.h(2206): error #2120: Redeclaration of '_InterlockedCompareExchange64', previously declared at B:\PellesC\Include\intrin.h(228); expected 'long long int __cdecl function(volatile long long int *, long long int, long long int)' but found 'long long int __fastcall function(volatile long long int *, long long int, long long int)'.
*** Error code: 1 ***
John
-
Version 1.25 ... >:(
-
It works! :)
However, does that mean other headers do not need testing?
John
-
It works! :)
However, does that mean other headers do not need testing?
John
Great! ;D
Of course this is only a 'static' fixing :) Meaning that base software can be compiled without compiler warnings nor errors ;D
The basic software 'Runs', but maybe some patches are wrong (especially on OLE/AUTO code).
Just a small part of more than 1k files have been touched:
- Windows.h
- WinNT.h
- WinBase.h
- ShellAPI.h
- ShlObj.h
- StrAlign.h
- Wmistr.h
- daogetrw.h
- dhcpsapi.h
- dhcpv6csdk.h
- driverspecs.h
- DSAdmin.h
- DtcHelp.h
- dvbsiparser.h
- intsafe.h
- mpeg2data.h
- mpeg2psiparser.h
- netmon.h
- sal.h
- xenroll.h
Other fixing will be required for 'special include files' that allows special advanced functions. :)
The point is that at the question: "So which header do you need?" nobody answered :(.
Everybody want all even if don't will never even think to use it! :(
Anyway this is a starting point, and still a work in progress for eventual errors/problems. Keep going ... 8)
-
Well you've done a grand job so far.
What about the new MS libs?
John
-
Well you've done a grand job so far.
What about the new MS libs?
John
Thanks John. :)
I got also a lot of help and support from Timo.
The libs need just to be copyied as far as I have checked up to now.
The only problem is with some debug symbols not recognized from PellesC. :(
Compiling without debug works well, for the other case we have two ways: a tool to remove (strip) debug section from libs, or to recreate them using polib ... :(
Another solution is to ask Pelle, as a feature request, to ignore unknown symbols instead of trigger an error. 8)
-
Frankie, Timo!
thank you very much for your work!
czerny
-
Frankie, Timo!
thank you very much for your work!
czerny
Thanks Czerny :)
As usual nobody even downloaded the tool (at this time there is only John's download).
As usual the whole project is a waste of time .... ::)
-
Frankie, Timo!
thank you very much for your work!
czerny
Thanks Czerny :)
As usual nobody even downloaded the tool (at this time there is only John's download).
As usual the whole project is a waste of time .... ::)
Yes the PellesC community are a strange lot.
When I started the web site for lcc-win32 there were hundreds of contributions, for the PellesC web site only a very few.
I guess we will never know why.
John
-
Hi Frankie,
Don't take the number of downloads as lack of interest. People tend to wait until the result is perfect...
My level of C is not sufficient to play with all your tools. What I have noticed, though, is that copy & paste from VS to Pelles C works fine in most cases, while it doesn't work the other way round. And the problem is VS, not Pelles C. Often it's because variables need to be declared before any code in VS - now I try to do that in order to remain compatible with VS.
I like Pelles C. It is fast to compile and simple to use. If MS standard headers can be used, too, more C noobs might be tempted to try Pelles C first before launching that behemoth of VS.
-
As usual nobody even downloaded the tool (at this time there is only John's download).
As usual the whole project is a waste of time .... ::)
I have not downloaded the tool by now. But I am sure I will do it in the future. I need a bigger junk of spare time to be engaged in this.
As you know, I would much more like a solution with spezial Pelles C header files than a set of patched MS-files. But your work is even than a big help!
So: Don't worry! Be happy!
-
Yes the PellesC community are a strange lot.
When I started the web site for lcc-win32 there were hundreds of contributions, for the PellesC web site only a very few.
I guess we will never know why.
John
Yeah! Strange indeed ;D ::)
I made some modification just for the communication sake, now the first post in the thread shows clearly what there is there and how to use it ... :(
then some tech info ... :P