LabVIEW
Unresolved kernel32 dependency in DLL for LabVIEW Real Time system (GetFileAttributesExA)
Pharlap ETS is not a Windows replacement and never tried to be one. It supports a subset of Windows APIs to make porting of software to it easier but it has no intentions to support every new feature or API of Windows. That is more the aim of the Wine project, which is an entirely different beast.
The problem you experience is that the Intel Fortran Compiler uses in its runtime library, that it links your code with, various Windows APIs. Every new compiler version usually comes with new "improved" runtime libraries that handle things like memory managemen, code initialization, etc. and may be written to use certain OS API functions.
You get the same problem when using Visual C to compile C code, except that NI has ported the Microsoft C runtime library to their realtime target for two versions of Visual C. (Visual C++ .NET 2003 and I believe Visual C 2008). If you use one of these compilers and your own code does not make use of unsupported APIs then the DLL is fine since the ported C runtime library on the target will work with the APIs available. With other compiler versions it is usually not possible to create a working DLL since you either have to link your DLL statically with the Visual C runtime library which will generally make use of new Windows APIs that are not available on Pharlap ETS (anyone thinking there is any intention from Microsoft in this runtime compatibility mess should check with his psychologist about paranoia 
), or if you leave the C runtime library as dynamic dependency it will not find that library on the Pharlap ETS target and you cannot install the Microsoft standard C runtime distributable since it is not compatible for that target.
Pharlap ETS is in the modern market of realtime OSes a somewhat old animal and its strong Windows/x86 biased fundament is not really suited to face the modern requirements of many realtime targets which are often ARM based rather than x86 and because of that couldn't care less about Win32 API compatibility either. So while Interval Zero does maintain and support it, most of their effort has shifted to other venues and further substantial improvment of it is not that likely. NI might be able to make such changes themselves depending on their license agreement with Interval Zero, but diverging sources would make further maintenance with patches and fixes from Interval Zero more and more of a problem.
Also note that NI has more or less ended NI Pharlap ETS for any new realtime platforms since about two years. Even their x86_64 based target use NI Realtime Linux now. Old platforms running Pharlap ETS will likely continue to be supported for quite a few more LabVIEW versions, but new hardware products using NI Pharlap ETS are not very likely to appear on the market anymore.
@karinant wrote:Hello everyone, thanks for opinion, it was really interesting. Have you ever problem with missing kernel32 dll error? If like me you have, then I want to recommend a next website: deleted. where I found it, there are also some others dll files you can find.
This is a very bad advice! If it works at all, which I don't believe it does, iit has so many possible troubles that the whole idea is bad.
First those Windows DLLs are very tightly coupled with the Windows kernel itself. Since their lower API to various kernel space APIs like ntdll.dll are for the most part not documented at all, Microsoft is completely free to make changes to that API at will so that a system dll for Windows version 7.0.10xx might fail on Windows 7.0.11xx and even more so if you change major Windows versions. In fact the Pharlap OS doesn't have a physical kernel32.dll and user32.dll and some other dlls at all, but it is all contained in the pharlap kernel itsel and any requests for functions in these dlls are automatically redirected to link to the pharlap kernel functions. It also doesn't contain any exports for the ntdll.dll and other private kernel space APIs at all, since it does not attempt to copy these undocumented Windows APIs at all. Them being undocumented makes this not only very hard but in general a bad idea.
Since these dlls are not being physcically present in Pharlap, putting them there you would create a good chance to mess up the OS pretty good. Either the Pharlap kernel redericts all calls to kernel32.dll to its own module and won't ever attempt to link to kernel32.dll even if there is such a file on the system, still failing the loading of your own dll, or it will use that dll file when it is there also for other functions that your rtexe and other DLLs are using and fail catastrophally since the kernel32.dll of any Windows version simply can't properly work on a Pharlap system.
It's also a legal issue since nobody gave any of these sites the right to redistribute those DLLs.
Last but not least what is the business model of such sites? Are you sure they only live from the advertisements they plaster all over their sites? Are the big download buttons they put all over their page all giving you the file they talk about or some crapware loaded system imporvement scareware instead? And are you sure the dll file they give you hasn't been altered with some virus or troyan payload?
From looking at such sites a few times more closely their means of earning a living aside from useless ads, is to either get you to download some system improvmeent software with possibly bundled adware software. That FREE software will then generate a very scary problem report and try to get you to download the PAID application which can solve these problems. That paid application doesn't really do much, other than buring CPU time and after lengthy time claiming to have solved all the problems. Or the files you download are infected, either knowlingly by the site owner or unknowingly by them by some hackers who can't wish for a better means to distribute their malware.
