- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thankyou for your reply re:converting from CVF to IVF. You advise that if there is code that depends on which compiler, to utilise
!DEC$ IF DEFINED (__INTEL_COMPILER)
which I will do - I assume __INTEL_COMPILER is defined automatically?
Or do I have to define it?
On a connected topic, the porting document mentions the 'new' default calling convention and how routine names are still uppercased, but there is no @n suffix added, although a leading underscore is. Well, my CVF code has directives such as the following (that I inherited), and I would welcome advice as to what they should be changed:
!DEC$ IF DEFINED(_X86_)
!DEC$ ATTRIBUTES STDCALL, ALIAS : '_WinMain@16' :: WinMain
!DEC$ ELSE
!DEC$ ATTRIBUTES STDCALL, ALIAS : 'WinMain' :: WinMain
!DEC$ ENDIF
!DEC$ ATTRIBUTES STDCALL, ALIAS : '_WinMain@16' :: WinMain
!DEC$ ELSE
!DEC$ ATTRIBUTES STDCALL, ALIAS : 'WinMain' :: WinMain
!DEC$ ENDIF
Thanks in advance.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IVF default calling convention is CDECL/uppercase/string length after all args. CVF default is STDCALL/uppercase/string length after string arg. Thus, no @n appended in case of IVF (and no LNK2001 if you mismatch the prototype of external routine :-(, only run-time error).
That doesn't matter in the case of WinMain or other Win32 procedures (WndProcs e.g.) -- since you have to spell out !DEC$ATTRIBUTES STDCALL (and ALIAS), you'll get the same (correct) result (_WinMain@16). The default calling convention shouldn't matter in any case, provided that you spelled out required prototypes where it was necessary.
Jugoslav
That doesn't matter in the case of WinMain or other Win32 procedures (WndProcs e.g.) -- since you have to spell out !DEC$ATTRIBUTES STDCALL (and ALIAS), you'll get the same (correct) result (_WinMain@16). The default calling convention shouldn't matter in any case, provided that you spelled out required prototypes where it was necessary.
Jugoslav
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You will probably have gathered that I do not like having to put up with either ALIASing or varying the order and number of arguments flagged for each function/routine. Why do we have to do this? It is still as clear as mud to me.
As an example, I quote WinMain, which is a function whose contentsI have tomodify to suit myself, but which I never call myself. So, I call it WinMain, as that is what the documentation calls the function that must be called by the Windows system to start a Win32 application (note, I am not told to call it __WINMAIN@16 or other variation). When it is compiled and the code put into an .OBJ file,I, in all my innocence, assume that somewhere in there will beentry point labelled with 'WinMain' that can be found (although,when compiled using a FORTRAN compiler, it will always be labelled WINMAIN apparently). However, I am also told that the calling Windows system program expects to find an entry point labelled '_WinMain@16', the number of underscores and final argument dressing being chosen totally at the discretion of this calling program (in this case a Windows system DLL or other program). So, I have to add compiler directives to inform it that WINMAIN is not acceptable in this case, but 'WinMain', or '_WinMain', or'__WinMain@16' is, depending on whatever the calling program expects but, here's the rub, I have no idea beforehand what the calling program expects. During linking, I may be told that '"[the linker] cannot find 'WhatEver@16", but annoyingly it is not intelligent enough to offer "but this is close to '_WhatEver@16'. Did you mean that?".
On the other hand, If I define a function XYZ myself and call it (reference it)myself, the compiler will, in the absence of directives to do anything else, be consistent in relabelling both the function name and each reference to it wherever they may occur in my code and will always 'find' the entry when linking. For all I know the compiler might relabel the function reference as__ABC@20, but this will be transparent as it will also know that wherever reference to 'XYZ' or 'xyz' or 'Xyz' occurs in the FORTRAN, it should replace it with reference to __ABC@20, so that all is well (but still annoying!).
To come back to my original gripe, it appears that CVF decorates routines and function references in one way and IVF another, but it would be nice to be told EXACTLY what form this decoration takes. So, taking XYZ (assumed to have5 arguments)as an example, does CVF turn it into '_XYZ@20' and IVF into '_XYZ', or whatever?
And how does IVF choose the correct referencetosupply for WinMain (_WINMAIN, _WinMain or _WinMain or variations with @16 added) since it has to satisfy a call from a Windows DLL which is independant of IVF and has made its own name-calling choice?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, taking XYZ (assumed to have 5 arguments) as an example, does CVF turn it into '_XYZ@20' and IVF into '_XYZ' , or whatever?
Yes, unless you tell it otherwise using ALIAS directive.
I must confess I don't understand the rationale beyond all your gripe :-). The only place where you really have to use the ALIAS is WinMain. The other places are INTERFACEs to routines written in other languages. And you have to have use the alias because "system" expects you to have "_WinMain@16".
However, please notice existence of "Entry point" edit box under "Linker" settings ("Output" in CVF, "Advanced" in IVF). That means that (in theory) you don't really have to use "_WinMain@16", but promote any routine you wish into the entry-point (however, it'd better be a STDCALL with 4 arguments). (When entering, just skip the leading underscore, e.g "WinMain@16"). Actually, the starting address of the entry-point routien is just an entry in .exe's PE header table.
"In theory" above means, though, that your own WinMain is not the real entry-point. The real entry-point is located in C run-time library (WinMainCRTStartup), and that functions calls your "_WinMain@16". See this MSDN entry. Thus, if you could manage not to use any C (or Fortran) RTL routine (which is hardly possible) you could use that linker setting. Otherwise, stick to naming your main program "_WinMain@16".
I'm not sure if my reply answered your question, but that was my 2c.
Regards
Jugoslav
Yes, unless you tell it otherwise using ALIAS directive.
I must confess I don't understand the rationale beyond all your gripe :-). The only place where you really have to use the ALIAS is WinMain. The other places are INTERFACEs to routines written in other languages. And you have to have use the alias because "system" expects you to have "_WinMain@16".
However, please notice existence of "Entry point" edit box under "Linker" settings ("Output" in CVF, "Advanced" in IVF). That means that (in theory) you don't really have to use "_WinMain@16", but promote any routine you wish into the entry-point (however, it'd better be a STDCALL with 4 arguments). (When entering, just skip the leading underscore, e.g "WinMain@16"). Actually, the starting address of the entry-point routien is just an entry in .exe's PE header table.
"In theory" above means, though, that your own WinMain is not the real entry-point. The real entry-point is located in C run-time library (WinMainCRTStartup), and that functions calls your "_WinMain@16". See this MSDN entry. Thus, if you could manage not to use any C (or Fortran) RTL routine (which is hardly possible) you could use that linker setting. Otherwise, stick to naming your main program "_WinMain@16".
I'm not sure if my reply answered your question, but that was my 2c.
Regards
Jugoslav

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page