SetPriorityClass - comp.lang.fortran

I'm trying to use the Win32 API SetPriorityClass so that a number cruncher will start out at idle priority and not affect system responsiveness. The documentation to CVF 6.6c for SetPriorityClass says that the import library is kernel32.dll, which is included by the linker by default, yet the linker gives an unresolved external error message for SetPriorityClass. What am I doing wrong?

On Jan 12, 4:45 pm, tho...@antispam.ham wrote: > I'm trying to use the Win32 API SetPriorityClass so that a number > cruncher will start out at idle priority and not affect system > responsiveness. The documentation to CVF 6.6c for SetPriorityClass > says that the import library is kernel32.dll, which is included by > the linker by default, yet the linker gives an unresolved external > error message for SetPriorityClass. What am I doing wrong? I would strongly suggest your asking this sort of question in the Intel Visual Fortran user forum, where CVF questions are welcomed and there are many users versed in the Win32 API. Your question is not related to the Fortran language. You can find the forum at http://softwarecommunity.intel.com/isn/Community/en-US/forums/1005/ShowForum.aspx In order to help you further, I'd want to know if you also added: USE KERNEL32 to your source. This would be required to get the proper name mapping. If so, the exact text of the error message(s) would be useful. Steve

Steve Lionel writes: >> I'm trying to use the Win32 API SetPriorityClass so that a number >> cruncher will start out at idle priority and not affect system >> responsiveness. The documentation to CVF 6.6c for SetPriorityClass >> says that the import library is kernel32.dll, which is included by >> the linker by default, yet the linker gives an unresolved external >> error message for SetPriorityClass. What am I doing wrong? > > I would strongly suggest your asking this sort of question in the > Intel Visual Fortran user forum, where CVF questions are welcomed and > there are many users versed in the Win32 API. Your question is not > related to the Fortran language. But it is related to a Fortran compiler, and such topics are rather frequent in this newsgroup. > You can find the forum at > http://softwarecommunity.intel.com/isn/Community/en-US/forums/1005/ShowForum.aspx > > In order to help you further, I'd want to know if you also added: > > USE KERNEL32 > > to your source. This would be required to get the proper name > mapping. At the time of the problem, I had not. I am usually reluctant to include or use a bunch of code whose content I am not familiar with, due to the possibility of a variable name collision. In this particular case, I only needed one mapping, which was determined fairly easily by examining the kernel32.f90 and dfwinty.f90 files (64 corresponds to idle priority). Indeed, after I added USE KERNEL32 to the source, the first problem I encountered was such a name collision, as I had used "Handle" for the process handle returned by GetCurrentProcess. But after resolving that issue, the program did compile and link properly, and now it sets its own idle priority, as desired. > If so, the exact text of the error message(s) would be useful. The problem is solved. Thanks. Part of me says that no additional information is needed, because I have what I wanted. Another part of me wants to know why the inclusion of USE KERNEL32 suddenly allowed the linker to resolve the external reference to SetPriorityClass. Usually an unresolved external means that one didn't specify the right library to the linker, but in this case I made no changes to the library list, so I am a bit puzzled as to why it now links.

On Jan 15, 4:36 am, tho...@antispam.ham wrote: > The problem is solved. Thanks. Part of me says that no additional > information is needed, because I have what I wanted. Another part of > me wants to know why the inclusion of USE KERNEL32 suddenly allowed > the linker to resolve the external reference to SetPriorityClass. > Usually an unresolved external means that one didn't specify the right > library to the linker, but in this case I made no changes to the > library list, so I am a bit puzzled as to why it now links. If you had posted the text of the linker error message, it would have said that _SETPRIORITYCLASS was undefined, because the defaults in Intel Fortran for Windows are that routines have the C calling convention and the names are upcased. However, the Win32 API routines use the STDCALL calling convention and their names are mixed case, so the name provided in kernel32.lib is _SetPriorityClass@8 which does not match _SETPRIORITYCLASS. Intel Visual Fortran provides a large number of predefined modules for Win32 API declarations. Think of them as the same as the various header files provided by MSVC, such as windows.h. These contain declarations of constants, types and routines in the Win32 API to enable easy use from Fortran. In the case of SetPriorityClass, an interface block is provided as follows: INTERFACE FUNCTION SetPriorityClass( & hProcess, & dwPriorityClass) import integer(BOOL) :: SetPriorityClass ! BOOL !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'SetPriorityClass' :: SetPriorityClass integer(HANDLE) hProcess ! HANDLE hProcess integer(DWORD) dwPriorityClass ! DWORD dwPriorityClass END FUNCTION END INTERFACE INTERFACE This declares the routine and arguments (also making sure that you pass the correct number and types of arguments), and changes the calling convention and external name to match that of the actual routine. As you found, there are some named constants defined for common Win32 datatypes, to be used as kind specifiers. These correspond, generally, to those documented by Microsoft for the Win32 API. HANDLE is one of them. Yes, you may have a name that conflicts with one of the symbols from the module. You can use ONLY or renaming clauses if this is an issue, or take the other approach and rename your identifier. By the way, you don't need to also USE IFWINTY, as this is implied by USE KERNEL32. Really, this is no different from the use of header files in C/C++. You don't HAVE to use them, but if you don't you'll generally need to "roll your own" substitute declarations to get the right semantics. I suggest you read the Intel Fortran documentation on use of the Win32 API. I also repeat my suggestion that the Intel Visual Fortran user forum is a better place for a question such as this, as it is specific to a vendor. I know that such topics are common here, but that doesn't mean this newsgroup is the best place for them. Steve Lionel Developer Products Division Intel Corporation Nashua, NH User communities for Intel Software Development Products http://softwareforums.intel.com/ Intel Fortran Support http://support.intel.com/support/performancetools/fortran My Fortran blog http://www.intel.com/software/drfortran

On Jan 15, 9:03=A0am, Steve Lionel <steve.lio...@intel.com> wrote: > On Jan 15, 4:36 am, tho...@antispam.ham wrote: > > > The problem is solved. =A0Thanks. =A0Part of me says that no additional > > information is needed, because I have what I wanted. =A0Another part of > > me wants to know why the inclusion of USE KERNEL32 suddenly allowed > > the linker to resolve the external reference to SetPriorityClass. > > Usually an unresolved external means that one didn't specify the right > > library to the linker, but in this case I made no changes to the > > library list, so I am a bit puzzled as to why it now links. > > If you had posted the text of the linker error message, it would have > said that _SETPRIORITYCLASS was undefined, because the defaults in > Intel Fortran for Windows are that routines have the C calling > convention and the names are upcased. =A0However, the Win32 API routines > use the STDCALL calling convention and their names are mixed case, so > the name provided in kernel32.lib is _SetPriorityClass@8 which does > not match _SETPRIORITYCLASS. > > Intel Visual Fortran provides a large number of predefined modules for > Win32 API declarations. =A0Think of them as the same as the various > header files provided by MSVC, such as windows.h. =A0These contain > declarations of constants, types and routines in the Win32 API to > enable easy use from Fortran. =A0In the case of SetPriorityClass, an > interface block is provided as follows: > > INTERFACE > FUNCTION SetPriorityClass( & > =A0 =A0 =A0 =A0 hProcess, & > =A0 =A0 =A0 =A0 dwPriorityClass) > import > =A0 integer(BOOL) :: SetPriorityClass ! BOOL > =A0 =A0 !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, > ALIAS:'SetPriorityClass' :: SetPriorityClass > =A0 integer(HANDLE) hProcess ! HANDLE hProcess > =A0 integer(DWORD) dwPriorityClass ! DWORD dwPriorityClass > =A0END FUNCTION > END INTERFACE > INTERFACE > > This declares the routine and arguments (also making sure that you > pass the correct number and types of arguments), and changes the > calling convention and external name to match that of the actual > routine. > > As you found, there are some named constants defined for common Win32 > datatypes, to be used as kind specifiers. =A0These correspond, > generally, to those documented by Microsoft for the Win32 API. =A0HANDLE > is one of them. =A0Yes, you may have a name that conflicts with one of > the symbols from the module. You can use ONLY or renaming clauses if > this is an issue, or take the other approach and rename your > identifier. > > By the way, you don't need to also USE IFWINTY, as this is implied by > USE KERNEL32. > > Really, this is no different from the use of header files in C/C++. > You don't HAVE to use them, but if you don't you'll generally need to > "roll your own" substitute declarations to get the right semantics. > > I suggest you read the Intel Fortran documentation on use of the Win32 > API. > > I also repeat my suggestion that the Intel Visual Fortran user forum > is a better place for a question such as this, as it is specific to a > vendor. =A0I know that such topics are common here, but that doesn't > mean this newsgroup is the best place for them. > > Steve Lionel > Developer Products Division > Intel Corporation > Nashua, NH > > User communities for Intel Software Development Products > =A0http://softwareforums.intel.com/ > Intel Fortran Support > =A0http://support.intel.com/support/performancetools/fortran > My Fortran blog > =A0http://www.intel.com/software/drfortran There are of course lots of good tutorials online; this one is fairly short and easy to understand (although not IVF related): http://ocliteracy.com/techtips/win32-callconv.html

tholen@antispam.ham wrote: > Steve Lionel writes: > >> In order to help you further, I'd want to know if you also added: >> >> USE KERNEL32 >> >> to your source. This would be required to get the proper name >> mapping. > > At the time of the problem, I had not. I am usually reluctant to > include or use a bunch of code whose content I am not familiar with, > due to the possibility of a variable name collision. You know that ONLY can help with this, right? You can make it so that only the stuff you actually need gets pulled in, reducing the chances of a name collision.