Compiler help

Is there a way to tell VC++ . net to compile for an os other then windows? Or can Metrowerks CodeWarrior compile for different operating systems? What I need is a c++ Compiler that compiles to either strait assembly or something like that. Because naturaly VC++ calls int 21 to make the calls to dos. So what i need is a c++ Compiler that runs on windows but can compile for another operating system, i dont care if i can test it or not.

VC++ doesn't call int 21h. It makes calls to the CRT, which in turn makes calls to Windows API functions (and occasionally replacing them for efficiency, such as memory management).

You can get cross-compilers, but they tend to be fairly specialised.

Oh, and all C++ compilers have options for producing the intermediate assembly listing (before it's assembled and linked). The normal process is:

Preprocess -> Compile/syntax check -> Assemble -> Link

The GNU compiler can act as a cross-compiler, but you need to compile it yourself to do that, which requires a Unix or GNU/Linux system.

The MSVC++ CRT memory functions don't do mem management themselves. They still use Heap* functions, but they use their own heap.

But take the source of the gcc standard library, compile it with MSVC++, link to it instead of the windows CRT and compile. The resulting files should be fit for GNU systems, provided of course you manage to run windows EXEs there (it is possible).

Quote:

---

Originally posted by CornedBee
The MSVC++ CRT memory functions don't do mem management themselves. They still use Heap* functions, but they use their own heap.

But take the source of the gcc standard library, compile it with MSVC++, link to it instead of the windows CRT and compile. The resulting files should be fit for GNU systems, provided of course you manage to run windows EXEs there (it is possible).

---

I thought malloc had its own allocation arena, allocated with HeapAlloc when necessary (to be faster than Windows' internal, more generic allocator)?

No, it just relays all calls more or less directly to HeapAlloc, using the handle of the CRT heap (which the CRT creates in _CRTmainStartup using HeapCreate or CreateHeap, forgot the name).

Hmm. They must have changed then, I thought they'd adapted theirs to do that. Borland's has always been faster, though ;)

Turns out we were both right. Here's the source of the MSVC++7 internal malloc base routine (finally called by every malloc-like function)

Code:

---

void * __cdecl _heap_alloc_base (size_t size)

{
#ifndef WINHEAP
        _PBLKDESC pdesc;
        _PBLKDESC pdesc2;
#endif  /* WINHEAP */


#ifdef WINHEAP

#ifndef _WIN64
        if ( __active_heap == __V6_HEAP )
        {
            void * pvReturn;

            if ( size <= __sbh_threshold )
            {
#ifdef _MT
                _mlock( _HEAP_LOCK );
                __try {
#endif  /* _MT */
                pvReturn = __sbh_alloc_block((int)size);
#ifdef _MT
                }
                __finally {
                    _munlock( _HEAP_LOCK );
                }
#endif  /* _MT */
                if (pvReturn)
                    return pvReturn;
            }
        }
#ifdef CRTDLL
        else if ( __active_heap == __V5_HEAP )
        {
            void * pvReturn;

            /* round up to the nearest paragraph */
            if ( size )
                size = (size + _OLD_PARASIZE - 1) & ~(_OLD_PARASIZE - 1);
            else
                size = _OLD_PARASIZE;

            if ( size  <= __old_sbh_threshold ) {
#ifdef _MT
                _mlock(_HEAP_LOCK);
                __try {
#endif  /* _MT */
                pvReturn = __old_sbh_alloc_block(size >> _OLD_PARASHIFT);
#ifdef _MT
                }
                __finally {
                    _munlock(_HEAP_LOCK);
                }
#endif  /* _MT */
                if ( pvReturn != NULL )
                    return pvReturn;
            }

            return HeapAlloc( _crtheap, 0, size );
        }
#endif  /* CRTDLL */
#endif  /* _WIN64 */

        if (size == 0)
            size = 1;
#ifndef _WIN64
        if (__active_heap != __SYSTEM_HEAP)
            size = (size + BYTES_PER_PARA - 1) & ~(BYTES_PER_PARA - 1);
#endif  /* _WIN64 */
        return HeapAlloc(_crtheap, 0, size);
}

#else  /* WINHEAP */

        /* try to find a big enough free block
        */
        if ( (pdesc = _heap_search(size)) == NULL )
        {
            if ( _heap_grow(size) != -1 )
            {
                /* try finding a big enough free block again. the
                * success of the call to _heap_grow should guarantee
                * it, but...
                */
                if ( (pdesc = _heap_search(size)) == NULL )
                {
                    /* something unexpected, and very bad, has
                    * happened. abort!
                    */
                    _heap_abort();
                }
            }
            else
                return NULL;
        }

        /* carve the block into two pieces (if necessary). the first piece
        * shall be of the exact requested size, marked inuse and returned to
        * the caller. the leftover piece is to be marked free.
        */
        if ( _BLKSIZE(pdesc) != size ) {
            /* split up the block and free the leftover piece back to
            * the heap
            */
            if ( (pdesc2 = _heap_split_block(pdesc, size)) != NULL )
                _SET_FREE(pdesc2);
        }

        /* mark pdesc inuse
        */
        _SET_INUSE(pdesc);

        /* check proverdesc and reset, if necessary
        */

        _heap_desc.proverdesc = pdesc->pnextdesc;

        return( (void *)((char *)_ADDRESS(pdesc) + _HDRSIZE) );
}

---

As usual you can't read it, but we get some clues.
Depending on compiler switches, it either calls __sbh_alloc_block, __old_sbh_alloc_block, HeapAlloc or directly handle the call internally. The sbh functions don't call HeapAlloc, niehter does the interal handling, those all use VirtualAlloc to get a large region, then distribute chunks of it.

But a debug run shows that with my configuration HeapAlloc is called.

Looks like it. I normally avoid looking at the internals of the C library for any platform, they're invariably unreadable (as you said).

I'm not really bothered as long as it works. To tell the truth, I didn't notice much difference between using malloc() and HeapAlloc().