All of a sudden my C51 v5.50 is spewing out screen output like this: [Enter loader...In loader] PRIVATE ALLOCATION: LA 1F40000 - 270 Bytes - handle 1721DC0 PRIVATE ALLOCATION: LA 1F50000 - 46960 Bytes - handle 1721DE0 (allocated 289115 bytes for fixup info) PRIVATE ALLOCATION: LA 1FA0000 - 4F000 Bytes - handle 1721E00 PRIVATE ALLOCATION: LA 1FF0000 - FC0 Bytes - handle 1721E20 PRIVATE ALLOCATION: LA 2650000 - 35000 Bytes - handle 1721E40 LINEXE: Using DOS:Extended Startup Conditions... Leave loader...Exit loader Executing C:\C51\BIN\C51.EXE with initial registers: TSF32: prev_tsf32 0 SS 2FF DS 2FF ES 18F FS 0 GS 17F EAX 0 EBX 0 ECX 0 EDX 0 ESI 2F7 EDI 0 EBP 0 ESP 2684490 CS:IP 2F7:01FE2600 ID 00 COD 60A2798 FLG 200 CS= 2F7, USE32, page granular, limit 7FFEFFFF, base 0, acc C7FB DS= 2FF, USE32, page granular, limit 7FFEFFFF, base 0, acc C7F2 ES= 18F, USE16, byte granular, limit 100, base 6580, acc F3 SS= 2FF, USE32, page granular, limit 7FFEFFFF, base 0, acc C7F2 From my point of view, it just started doing it by itself; I didn't do anything that I know about to cause this. I have re-installed and restarted, and no change. Any idea what's up with this?
Thanks for responding. While I can safely ignore the output, it does make it hard to find compiler and linker error messages. Listed below are the environment variables in my system. I don't see anything promising here. What about the registry? Does Keil use that in C51 v5.50? This all started, not surprisingly, after a session using the National Instruments' LabVIEW development environment, where I was allocating huge arrays for the first time. This wouldn't be the first time LabVIEW corrupted unrelated resources in my system. Weird, huh? ALLUSERSPROFILE ALL_SOURCE APPDATA BUILD_LIST BUILD_TYPE C51INC C51LIB CommonProgramFiles COMPILER COMPILER_PATH COMPUTERNAME ComSpec CONVERTER C_INCLUDE_PATH DEVROOT DO_BUILD DO_LOAD HOMEDRIVE HOMEPATH INCLUDE KMP_DUPLICATE_LIB_OK LINKER LINKER_OPTS1 LOADER LOADER_OPTS LOGONSERVER MAKE_ALL_LIST MKL_SERIAL NIDAQmxSwitchDir NUMBER_OF_PROCESSORS OBJS OS Os2LibPath Path PATHEXT PIN_PATH PROCESSOR_ARCHITECTURE PROCESSOR_IDENTIFIER PROCESSOR_LEVEL PROCESSOR_REVISION ProgramFiles PROMPT PYTHONPATH SLKRUNS SOURCE0 SOURCE1 SOURCE2 SSDIR SSUSER SystemDrive SystemRoot TEMP TEST_ONLY TMP USERDNSDOMAIN USERDOMAIN USERNAME USERPROFILE VSDIR VSDRIVE VSLICKBACKUP VSLICKBIN VSLICKINCLUDE VSLICKMACROS VSLICKMISC VSLICKPATH VSROOT VXIPNPPATH windir
[Note: Toolset selection changed to reflect program actually in use] What about the registry? Does Keil use that in C51 v5.50? It's a DOS program. It doesn't even know the registry exists. You do seem to have altogether too many environment variables set. Looks like you have all variables used by several development toolchains active in the environment at the same time (e.g. 3 separate C include file search paths at least...). While that may work if you're lucky, it's hardly ever a very good idea. Among other issues, it's nearly guaranteed to cause problems with PATH ordering --- some tool is almost invariable going to be found in the wrong directory. My guess, given the symptoms, would be that NI modified your PATH, so a different copy of DOS4GW.exe is now found instead of the one distributed with your Keil C51. So: check your PATH, and consider separating environments to be used for different compilers, either by setting up several independent shell window links, each with their own startup files to set the variables, or by setting up separate user accounts per toolchain. It's quite a bit of work to get it going, but it pays off by having a more stable system in the long run.
No copy of DOS4GW.EXE exists in my environment or on any networked volume accessible to my machine. When I run C51, I watch the Win2K Task Manager Process window, sorted by Image name, for DOS4GW.EXE to appear, and it does not. Keil has apparently embedded some subset of this software into C51.EXE. The number of environment variables or their content does not appear to be a factor. They have all been there for a long time, required by my varied workload, and this problem started two days ago. That's why I though re-installing Keil would fix it, but it didn't. When I called Tenberry.com, the firm that evidently produced DOS4GW.EXE, the machine said that the voice message box is full. Bad sign. I'll try emailing them, but I'm not holding my breath. Their web page was last updated over a year ago.
"When I called Tenberry.com, the firm that evidently produced DOS4GW.EXE, the machine said that the voice message box is full ... Their web page was last updated over a year ago." Hardly surprising, really - there isn't much call for DOS extenders these days! This is always the trouble with hanging on to outdated development systems... :-(
The number of environment variables or their content does not appear to be a factor. They have all been there for a long time But has their content remained unchanged in all that time? Are you sure your PATH hasn't been tampered with? Would you know if any of your environment variables' contents had been changed? And, BTW: is the environment you listed the DOS one, or the Win32 one? The two can be different. You'll have to explicitly run command.com, not cmd.exe, to get to see the DOS version.