This document contains issues that are specific to the Alpha platform and does not replace the main Visual C++ readme file, READMEVC.HTM, which contains issues that are largely common to both Alpha and x86. You should read and understand both documents before using Visual C++ 6.0.
Three Alpha-specific documents are included on this CD: ASAXP.CHM, CGAXP.CHM, and PGAXP.CHM. Instructions on integrating these Alpha-specific documents into MSDN are included later in this file.
After installation is completed, you can find the Alpha Assembler, ASAXP.EXE, in the \VC98\BIN directory on your installation drive.
If you have an existing pre-release installation of Visual C++ 6.0 on your system, follow these steps before beginning VC++ setup:
Installation Issues
Visual C++ now on 2 CD’s
Visual C++ 6.0 for Alpha now comes on 2 CD’s. The Data Access SDK, Data Access Objects SDK, and Windows NT Option Pack are now on CD 2. Because these components each have their own installation programs, VC++ setup is unaffected.
Installing Alpha-specific documentation
The current release of MSDN does not include the Alpha-specific portion of the Visual C++ documentation. The Alpha-specific documentation is included on your VC++ CD1 instead. The following instructions will integrate the Alpha-specific VC++ documentation into a MSDN 6.0 or MSDN 6.0a installation.
To install the Alpha-specific documentation
The installed version(s) of MSDN are listed.
If you have more than 1 version of MSDN installed
If you have more than 1 version of MSDN installed, use the Add/Remove Programs applet in the Control Panel to completely remove the older version(s) before continuing.
For example, if the Microsoft Developer Network Program Group lists the following, use the Add/Remove Programs applet in the Control Panel to remove versions 6.0 and 6.0a of MSDN, while leaving any library updates (in this case, October 1998) and version 6.1 installed.
The Alpha-specific VC++ 6.0 documentation will be available next time you start MSDN.
Because of differences in development schedules, issues dealt with for x86 in SP1 have been already addressed in this release for Alpha. Consequently, there will not be an equivalent Service Pack 1 for the Alpha Edition of VC++ 6.0.
This version of VC++ for Alpha contains an upgrade to NT4 SP3. You may obtain an upgrade to NT4 SP4 at http://www.microsoft.com/ntserver/nts/downloads and follow the links under "Recommended Upgrades." In addition, this version of VC++ for Alpha contains MDAC 2.0. There are known Y2K issues in the 2.0 release of MDAC. You should monitor http://www.microsoft.com/data for information on upgrades that will address these issues.
Edit and Continue
The Edit and Continue feature is unsupported in Visual C++ Version 6.0 for Alpha. This feature is planned for inclusion in a future release of Visual C++ for Alpha.
HTMLHelp Workshop
HTMLHelp.exe is a self-extracting executable that installs HTML Help Workshop, the complete authoring and build environment for developing HTML Help files (.CHM). The kit is located in the HTMLHelp directory of your VC++ 6.0 CD1.
The Alpha Edition of VC++ 6.0 does not include an Alpha-native version of the HTML Help Workshop kit. In addition, the x86 version of the HTML Help Workshop kit does not run on Alpha systems, even if FX!32 is installed.
To author HTML Help files, install HTMLHelp.exe onto an x86 system. Keep in mind that the .CHM files you create are platform independent and are viewable on both x86 and Alpha systems.
Note When copying HTML Help files between platforms, be sure to copy both the .CHM and .CHI files.
Compiler might run indefinitely with maximum inlining and other optimizations specified
Under certain very rare circumstances, when maximum optimizations (/Ox), optimizations for size (/Os), and maximum inlining (/Ob4) are all specified (/Osxb4), the compiler might run indefinitely.
There are a number of alternative ways to work around this issue. First, the following three optimization changes have been found to eliminate this behavior:
Second, you may insert a “return appropriate_value_of_appropriate_type” statement after the control construct that is causing the behavior.
New linker switch /debugtype:fixup
This new linker switch causes the linker to preserve relocation records it gets from the object file.
Compiler does not accept documented architecture tuning options as shown in CL /?.
The Alpha compiler allows a variety of processor tuning options. These are listed in the Command-Line compiler help as /QAarch {21164, 21164A, 21164PC, 21264, host}.
For this release, these options are not accepted, rather the corresponding processor "Engineering Version" numbers are. The specific accepted options are: /QAarch{EV4, EV5, EV56, EV6, host}.
A fix is planned for the next release of the product.
Code sequences which contain "while(0)" or "while(FALSE)" constructs are optimized away.
Code sequences which contain "while(0)" or "while(FALSE)" constructs are optimized away completely, even at optimization level /Od. If usage of these constructs is critical, a work around is to define a variable "i = 0;", then use "while(i)" instead.
Note that at optimization levels greater than /Od, the constant "i = 0" will be propagated to the "while(i)" construct, and the “while” loop will be optimized out of the code. This behavior is expected to remain the same in future versions of the compiler.
Unused or unreferenced external symbols can cause unexpected behavior.
In some cases when external symbols are defined in files, but neither used nor referenced by any code in that file, the reference will still be placed in the object file when the /Od compilation flag is used.
This behavior differs from the x86 edition of the product and might generate linking errors when the definition of the symbol cannot be found. In rare cases the external reference may force other files to be linked, in turn possibly overloading global references and subsequently altering program behavior.
This is normal behavior. Verify that no unused or unreferenced external references remain in your project before compiling and linking your project.
Enabling ATL Debugging
If you have enabled _ATL_DEBUG_INTERFACES, and encounter an error similar to the following:
error LNK2001: unresolved external symbol "public: virtual long _ _cdecl ATL::_QIThunk::f431(void)" (?f431@_QIThunk@ATL@@UAAJXZ)
You can correct this error by including QITHUNK.LIB on your linker command line and re-linking your program.
Call stack not visible in Windows NT DLLs
Stepping into an NT DLL such as NTDLL.DLL or USER32.DLL results in the call stack being limited to the current routine. Subsequently stepping out to a non-NT program or DLL restores the complete call stack. This problem does not occur on other types of DLLs, either debug or release, with or without debug information.
Poor stack unwinding by the debugger
Consider the following code:
void main(void)
{
try {
throw 1;
}
catch( ... )
{
}
}Here is what the call stack looks like when stepping through before the throw statement is executed:
main() line 4
mainCRTStartup() line 257 + 28 bytes
KERNEL32! 77e8f500()Here is what it looks like afterwards:
main line 6
_NLG_Return2 address 0x004021c8
?_DestructExceptionObject@@YAXPAUEHExceptionRecord@@E@Z + 2968 bytes
?_DestructExceptionObject@@YAXPAUEHExceptionRecord@@E@Z + 1472 bytes
?_DestructExceptionObject@@YAXPAUEHExceptionRecord@@E@Z + 756 bytes
_InternalCxxFrameHandler + 476 bytes
CxxFrameHandler + 68 bytes
NTDLL! 77f504c4()
The stack is intact after the handler has been stepped through.
This issue is tied to Windows NT4, and will be fixed after the underlying operating system issue is fixed.
JIT OLE debugging not working properly
In some cases, if you try to debug an OLE client, VC++ does not open a new IDE window.
To workaround this issue, load the server and the client into two separate instances of the IDE, set breakpoints in both the client and server code, then run.
Breakpoints must be reset when restarting a debugging session
If you try to restart a debugging session, any previously set breakpoints will be lost because Alpha reloads all registers and temporary memory already in use the by code. You must reset any desired breakpoints.
This limitation is planned to be addressed in the next release of VC++ for Alpha.
Debugger does not properly Step Over a call when a Data breakpoint is enabled
If you try to Step Over a subroutine call when a Data breakpoint is enabled, the debugger will instead Step Into the subroutine. Execution may actually be in system library NTDLL at that point, requiring Stepping Out several levels before arriving at user code.
To work around, Disable the breakpoint (ALT+E+K), Step Over the subroutine, and Reenable the breakpoint. If you forget to Disable the breakpoint, break into the debugger (ALT+D+B), Disable the breakpoint, and continue debugging.
Error when debugging using Set Next Statement if current while( ) is true
If you select the Set Next Statement menu item when debugging an application, and the currently executing while( ) is true, a dialog stating "This operation will cause the current location to move to a different function" might be displayed. If you click OK and continue debugging (F5), you get an ACCVIO error.
This issue is being investigated.
Compiler does not silently ignore the /Gr switch
The Alpha Programmer’s Guide states that the compiler silently ignores the /Gr switch. Although this option is ignored, the compiler does emit a warning.
Profiler not working properly when used with some debug MFC applications
During the second phase of prep, prep /m is called to merge the results back in to the table. In certain rare cases, prep instead returns error PRF1012: "Cannot read expected number of bytes from \FILENAME.PBO" when profiling some debug MFC applications.
FIXUPS.EXE utility added to VC++ for Alpha
The FIXUPS.EXE utility uses the Windows NT profiling facility to monitor and isolate unaligned memory accesses. You can find the Fixups utility and FIXUPS.TXT, which describes the utility, in the \COMMON\TOOLS directory of your VC++ 6.0 CD1.
AutoWatch window does not display all variable watches
In some cases, the AutoWatch window does not display same variables as the x86 edition of VC++.
The workaround is to add the variable of interest to the Watch window, or to observe the Local-Watch window.
Thread ID in thread window missing or incorrect
When working with multithreaded applications you might encounter situations where the Thread window displays either the wrong thread ID or no thread ID at all. This occurs when ThreadName is used to name threads.
The workaround is to manually associate ThreadID with ThreadName. You can do this by selecting each thread separately in the Thread window. This causes the debugger to update and record the function name with each ThreadID.
Using the PVIEW utility might also be helpful.
A fix is planned for the next release of the product.
Problems with _ _asm statement formatting
If you encounter problems with _ _asm statement formatting, be aware that the first four bytes in a character string must be blank, as illustrated in the highlighted code in the following sample.
#ifdef __cplusplus
extern "C"
#endif
long __asm(const char *, ...);
#pragma intrinsic(__asm)
. . .
This formatting restriction will be removed in the next release of VC++ for Alpha.
Error when inserting 2 Wallet application controls into a project
Inserting either of the following 2 Wallet application controls into a project results in the error "Unable to open the Active X control. Make sure the control contains a valid Type Library." The controls both reside in the ACTPMNT.OCX file:
MSADDRESSSLIDE SELECTOR
MSPAYMENTSLIDE SELECTOR
This issue is related to Internet Explorer and is under investigation.