make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug report: Compile with Microsoft and Intel compiler


From: Eli Zaretskii
Subject: Re: Bug report: Compile with Microsoft and Intel compiler
Date: Wed, 27 Apr 2005 12:37:22 +0300

> From: =?iso-8859-1?Q?Jerker_B=E4ck?= <address@hidden>
> Cc: <address@hidden>
> Date: Wed, 27 Apr 2005 06:09:20 +0200
> 
> The critical errors are the local redefines of CRT functions - this must be
> solved to at least get make.exe built at all.

Sorry, I'm not sure I understand: what errors are those that
``redefine CRT functions''?

Anyway, I think I suggested how to solve each one of the errors with
conflicting prototypes, so the case of CRT functions should be taken
care as well.

> The missing header direct.h is also needed.

I suggested a different way of dealing with this, see my other mail
today.

> 1) For a complete accurate access to any questions on the Microsoft C
> runtime library, please look here:
> http://msdn.microsoft.com/library/en-us/vclib/html/vcrefRunTimeLibraryReference.asp

I know about MSDN, but it is sometimes much better to ask you (or
someone else with MSC development environment installed) to answer
questions, since I don't have the include files to look into, nor any
possibility to try compiling things to verify my hypotheses.  By
contrast, wading through the endless (and annoyingly slow) MSDN pages
is not an efficient way of investing my time.

> 2) On function calls into the Win32 platform, the right place to look is the
> Win32 platform SDK.

I don't have any easy way of looking there, since I don't have the
Microsoft development environment installed on any of my machines.

> Unfortunately Microsoft have "messed" up the
> documentation on recent releases and rearranged parts so things are not so
> easy to find any more. MSDN is huge so the best thing to do is search.

These deficiencies of the MS documentation is why I'm asking questions
instead of wasting my time looking in those places.

> 3) Lets forget about __cdecl. This support is not vital.

Agreed.  So next time you try building (hopefully, after we find a way
to fix some of the problems), please don't use the command-line
switches that tell the compiler to use a non-__cdecl interface by
default.  Let's see how many _real_ problems we have left, and take
care of them first, okay?

> 4) Also, please understand that the I/O and memory management used in the C
> runtime library is actually handled by the Win32 platform. The CRT is only a
> general basic compatibility layer. For complete file and memory handling you
> need to call directly into Win32. Things like file security, hardlinks,
> mount points, virtual memory mapped files etc. will only be accessible
> there. Mixing these two techniques would not be a good idea.

I know that much about Windows, but are you talking just principles
(in which case I agree), or are there some specific parts in what you
reported that need direct calls to the Win32 API?  If the latter,
please point out those cases, because I don't think I identified any
of them in the problems you reported.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]