Re: SysAllocString

"George" <George@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:61889BD3-EB97-4556-915C-E076085E31B5@xxxxxxxxxxxxx
1. Windows API is more compatible, since we use some version Windows
API (and related SDK) and it is supposed to work with another version
of Windows API (runtime);

You don't build with a specific version of Windows API. Your executable
just mentions API functions by name. The implementation of the API
functions is part of the operating system, and is installed when Windows
is installed. When the executable runs, it uses whatever implementation
of the API functions (again, bound by name) exists on the machine it is
running on.

Yes, Microsoft goes to great lengths to ensure that a particular named
function behaves the same on all Windows versions it is supported on.
That's how you can run the same binary on different OS versions without
having to recompile.

2. CRT (do you man C Runtime Library? :-)) is less compatible
compared with Windows API? For example, you mentioned if we build
with one version CRT (compiler/SDK) and if we run it with another
version CRT runtime, it is not supposed to work well 100%?

You generally can't do that. When you build with a particular CRT
version, you have to ship this version with your application (a CRT is
not part of the OS, you shouldn't expect it to be installed and ready
for your application). If you link to CRT statically, a copy of the CRT
is physically embedded in your binary (which also naturally leads to
your shipping the CRT with your application).

The problems begin when you have multiple modules (binaries) running in
your process (an EXE and several DLLs), each with its own version of the
CRT or using no CRT at all. A pair of complementary CRT functions (e.g.
malloc/free, fopen/fclose) works together when both functions come from
the same CRT instance, but generally doesn't work if the two functions
come from different copies of the CRT (even if the same version). This
means that you cannot, in general, allocate memory with malloc in one
module, pass the pointer to another, and successfully deallocate it with
free in that other module. Or fopen a file in one module, pass FILE*
pointer to the other, and fclose it there. On the other hand, you can
happily open a file with CreateFile, pass HANDLE to another module, and
CloseHandle there, because CreateFile and CloseHandle are Windows APIs
and all the modules in the process (and indeed, all processes on the
machine) use the same copy of the API.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Re: VBA / VBS to get Desktop folder string
    ... How I am supposed to know how reliable the API is, ... programmers who design these applications make use of environment variables ... bypassing the Windows API set up for just this purpose, ... written will always be more secure than the Windows Registry, ...
    (microsoft.public.access.modulesdaovba)
  • Re: Most elegant way to read to allocatable array?
    ... software (e.g. Windows API). ... It would be nice to have an API that can access some of the internal information stored by the run time or OS and to be able to coordinate IO across DLLS ... I have seen cases where I wanted to use 2 3rd party libraries, ... That may be because every handle I've been exposed to is simply an integer ID, similar to an LFN. ...
    (comp.lang.fortran)
  • Re: SysAllocString
    ... It is appreciated if you could list the DLL and import library file names ... for Windows API and CRT. ... CloseHandle there, because CreateFile and CloseHandle are Windows APIs ...
    (microsoft.public.vc.language)
  • Re: VBA / VBS to get Desktop folder string
    ... How I am supposed to know how reliable the API is, ... programmers who design these applications make use of environment variables ... bypassing the Windows API set up for just this purpose, ... written will always be more secure than the Windows Registry, ...
    (microsoft.public.access.modulesdaovba)
  • Re: SysAllocString
    ... Windows API is more compatible, since we use some version Windows API ... you mentioned if we build with one version CRT ... particular compiler, often to a particular version of a particular ... deallocated by a complementary CRT function in another module. ...
    (microsoft.public.vc.language)
Quantcast