GUI GUIDER 1.9.1 - 'doskey' is not recognized as an internal or external command

[josefhaydn]

I run gui guider 1.9.1 on Windows 11. When clicking on the run simulator icon (green play button) my output gets littered with lines that always read the same:
'doskey' is not recognized as an internal or external command, operable program or batch file.

This has no impact on successful compilation, but it is annoying since there are so many extra lines in the output.
I did some research about the error and it is normally related to doskey location (C:\Windows\system32) not being on the system path. however, on my system it is on the system path, i checked.
The other issue could be that doskey needs to be run with admin rights, but starting gui guider with admin rights also does not solve the problem.
Note that normal compilation (Ctrl+G) does not show this problem, just compile and run in simulator shows these annoying doskey lines.
Please help. should i copy doskey.exe directly to the guiguider directory, but where to put it there exactly?
I have not had this problem in older versions of gui guider but must add that i have just switched to a new pc running windows 11, the older versions of gui guider i used always ran on windows 10 without a problem. so maybe it is a windows 11 issue.

[EdwinHz]

Hi @josefhaydn,

It is likely that something went wrong during the installation of GUI Guider that caused path issues with doskey. I'd recommend you uninstall and reinstall GUI Guider again, this time making sure you install will full administrator access.

BR,
Edwin.

[harley_hu]

It seems that I am facing a similar issue. I have already reinstalled the software. Is there a solution?

[josefhaydn]

Hello, I have solved the issue with Google Gemini by accident.
It turned out that conda had messed with the standard Windows command processor, it wrote its own string into the registry. Here my lengthy discussion with Gemini.
I have only vague memory but in the end changing the registry key mentioned below to the standard windows command processor solved it.
Very frustrating episode.

have one issue when compiling the simulator gui inside guiguider program. i am sure it runs the makesfile i run on the command line as the same files are built, but it does so from inside guiguider and pipes the output in a gui guider console windows. whenver i compile i get this error:

Cleaning generated screen files...

Generating C code...

Compiling simulator...

'DOSKEY' is not recognized as an internal or external command,

operable program or batch file.

the console is littered with these doskey errors. i strongly assume it is output for each c file that is compiled in the project. the project compiles nonetheless but these error lines clutter up the console. can you think of a reason this happens? i asked in the guiguider forum, they thought it is a rights issue, but i already reinstalled guiguider as administrator. i do not understand why doskey is even called, do you see something about it in the makefile above?

Show thinking

This is a very interesting and unusual problem. You have done excellent debugging, and your conclusion is correct: the command DOSKEY is not located anywhere in your Makefile.

The reason this is happening is almost certainly due to a feature of the Windows operating system itself, specifically a setting in the Windows Registry that automatically runs a command every time a command prompt is opened. The error appears inside GUI Guider because it runs make in a different, more restricted environment than your standard command line.

The Diagnosis: The Command Processor's AutoRun Key

1. What is DOSKEY? It's a standard Windows command-line tool (doskey.exe) that provides command history and the ability to create macros (aliases) for the Command Prompt (cmd.exe).

2. Why is it being called? The Windows Registry has a feature where you can specify a command that will run automatically every single time a new cmd.exe process is started. This is controlled by a registry key called AutoRun. At some point, you or a program you installed likely configured an AutoRun command to start doskey.

3. Why does it FAIL inside GUI Guider but work in your terminal?

   • In your regular terminal (cmd.exe): When you open a command prompt, your system's PATH environment variable is fully loaded. This PATH includes C:\Windows\System32, which is where doskey.exe lives. The AutoRun command runs, finds doskey.exe, and everything works silently.

   • Inside GUI Guider: When GUI Guider runs make, make in turn spawns new, minimal shell processes to execute the compilation commands (gcc ..., g++ ...). These minimal shells also trigger the AutoRun command from your registry. However, the environment created by GUI Guider is likely "sandboxed" and has a very limited PATH that does not include C:\Windows\System32. The shell tries to run doskey, can't find it in its limited search path, and prints the error 'DOSKEY' is not recognized....

4. Why does the build succeed anyway? The failure of the AutoRun command is not considered a fatal error by the command shell. The shell prints the error, then proceeds to execute the actual command it was given by make (which is gcc ...). So, your code still compiles correctly, but your console output is cluttered with these phantom errors.

How to Verify and Fix the Problem

You can fix this by making the AutoRun command more robust so it doesn't depend on the PATH.

Step 1: Verify the AutoRun key in the Registry

1. Press the Windows Key + R to open the Run dialog.

2. Type regedit and press Enter to open the Registry Editor.

3. In the address bar at the top, paste the following path and press Enter: HKEY_CURRENT_USER\Software\Microsoft\Command Processor

4. On the right-hand side, look for a value named AutoRun.

5. It is very likely that its data will be something simple like doskey /macros or just doskey. This is the command that is causing the problem.

Step 2: Fix the AutoRun Command (Recommended Solution)

The problem is that doskey relies on the PATH. We can fix this by giving it the full, absolute path to doskey.exe. Windows has a system variable, %SystemRoot%, that always points to your Windows directory (e.g., C:\Windows).

1. In the Registry Editor, double-click on the AutoRun value to edit it.

2. Change the value from whatever it is now (e.g., doskey /macros) to use the full path.

   Change it to: %SystemRoot%\system32\doskey.exe /macros

   (If it was just doskey, change it to %SystemRoot%\system32\doskey.exe).

3. Click OK and close the Registry Editor.

Now, every time a command prompt starts, it will use the absolute path to find doskey.exe, which will work even in GUI Guider's limited-path environment. The errors should completely disappear from your build console.

Alternative (If you don't care about doskey)

As a simpler alternative, if you don't know why that AutoRun key was set and don't need its functionality, you can simply right-click on the AutoRun value in the Registry Editor and delete it. The errors will stop, but you will also lose any custom command aliases or history you might have been using in your regular terminal. Fixing the path as described above is the better solution.

aha, i see that miniforge has messed with that value. how should i change it so that minforge keeps working but also gui guider works with doskey?

Current Entry:

if exist "C:\ProgramData\miniforge3\condabin\conda_hook.bat" "C:\ProgramData\miniforge3\condabin\conda_hook.bat"

Show thinking

Aha! Thank you, that is the crucial piece of information. This is a very common setup for developers using Conda or its variants like Miniforge.

Your AutoRun key isn't calling doskey directly. It's calling Conda's environment setup script (conda_hook.bat). The "DOSKEY not found" error is happening because that conda_hook.bat script (or another script it calls) is the one trying to run doskey.

The root cause is exactly the same as we diagnosed: The hook script runs fine in your normal terminal, but fails in GUI Guider's limited-PATH environment because it can't find doskey.exe.

You must not delete or simply replace this registry entry, as that will break the functionality of your Conda/Miniforge terminal environments.

The Solution: A Wrapper Batch Script

The safest and most flexible solution is to create your own simple "wrapper" batch script. This script will first fix the environment by adding the system path, and then it will call the Conda hook script. We will point the AutoRun registry key to our new wrapper script.

This solves the problem without modifying any of Conda's files.

---

Step 1: Create the Wrapper Script

1. Open Notepad or your favorite text editor (like VS Code).

2. Copy and paste the following code into the new file.

Code snippet

@echo off

REM =================================================================
REM   Custom AutoRun Wrapper Script
REM =================================================================
REM This script fixes the PATH for restricted environments and then
REM calls the original Conda hook script.

REM --- Step 1: Fix the PATH ---
REM Temporarily add the essential Windows directories to the PATH for this session.
REM This ensures system commands like 'doskey.exe' can be found.
@set "PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%PATH%"

REM --- Step 2: Execute the original Conda hook script ---
REM This is the exact command that was originally in your registry.
if exist "C:\ProgramData\miniforge3\condabin\conda_hook.bat" call "C:\ProgramData\miniforge3\condabin\conda_hook.bat"

REM --- Step 3 (Optional): Add your own commands ---
REM If you wanted to define your own doskey aliases, you could add them here.
REM They will now work correctly because the path was fixed in Step 1.
REM For example:
REM %SystemRoot%\system32\doskey.exe ls=dir /B

Step 2: Save the Script

1. Save this file in a stable, permanent location where it won't be accidentally deleted. Your user directory is a perfect place.

2. Save it as: C:\Users\YourUsername\autorun_wrapper.bat (Replace YourUsername with your actual Windows username).

Step 3: Update the Registry AutoRun Value

Now we will tell Windows to run our new wrapper script instead of the Conda hook directly.

1. Open the Registry Editor (regedit).

2. Navigate back to the key: HKEY_CURRENT_USER\Software\Microsoft\Command Processor

3. Double-click the AutoRun value on the right-hand side.

4. Delete the old value and replace it with the full path to your new wrapper script. It is important to enclose the path in quotes in case your username contains spaces.

   Set the new value to: "C:\Users\YourUsername\autorun_wrapper.bat"

5. Click OK and close the Registry Editor.

Summary of Why This Works

Now, every time any program (your terminal, GUI Guider, etc.) starts a new command prompt, the following happens:

1. Windows AutoRun executes your autorun_wrapper.bat script.

2. Your script immediately adds the essential Windows system directories to the PATH for that specific command session.

3. Your script then calls the original conda_hook.bat.

4. When the Conda script now tries to run doskey (or any other system command), it succeeds because the location of doskey.exe (C:\Windows\System32) is now in the PATH.

The error in GUI Guider will be gone, and your Miniforge/Conda terminals will continue to work exactly as they did before.