#72 A failure that leaves me stumped

[Manfred Zindel]

Here I have a problem here that leaves me stumped:
The crucial first step whenever starting KISS.lgo is to execute the following script:

echo off
echo %cd% | clip
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderHeight /t REG_DWORD /d 100
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.FaceName       /t REG_SZ    /d Consolas
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.Height         /t REG_DWORD /d 0xFFFFFFF0
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.Weight         /t REG_DWORD /d 190
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.Italic         /t REG_DWORD /d 0
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.CharSet        /t REG_DWORD /d 0
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.OutPrecision   /t REG_DWORD /d 3
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.ClipPrecision  /t REG_DWORD /d 2
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.Quality        /t REG_DWORD /d 1
reg add HKCU\Software\FMSLogo /reg:32 /f /v CommanderFont.PitchAndFamily /t REG_DWORD /d 31
"%~dp0\_local_FMSLogo_RO_\fmslogo.exe" -W 15360 -H 8640 -L _base_RO_\first.lgo

This script follows a proposal of you, David, years ago that helped me to turn Little_Helper, the core of KISS.lgo, into a containerized system, which now has been tested in schools for over two years successfully.

In addition to some text-processing preparations, the primary function of theabove lines is to pass the current path to the invoked FMSLogo program, where it is further processed and permanently stored for use. How this is done, you can see in the introductory description of the starting procedure in a file base_RO_enter_.lgo:

MAKE "startup [activate_and_prepare]

TO activate_and_prepare
  messagebox [info] [Here I am]
;---------:---------:---------:---------:---------:---------:-----
; First, try to get the root path from the starter, then check it.
; After establishing the correct path to the root directory as
; the first important control-variable for permanent use, initialize
; more control-variables for completing the whole set. Bury it.
;
; Check all folders and files of the KISS.lgo-framework, taking
; their existence as "conditio sine qua non" of a correct frame.
; bury_root_path_from_launch, @.ntr.m.trim_string, and check_root_path.
;
; load the collection of procedures which is under development
; from its storage _cop.lgoto the workspace. 

; Finally erase the main procedure act itself - the workspace only
; keeps the project you develop and the buried (hidden) root path.
; While your project is under development, Little Helper is loaded,
; but it is buried as a whole. You can use it while it's invisible.
;---------:---------:---------:---------:---------:---------:-----

But when starting, since approximately 4 weeks the procedure activate_and prepare in file enter.lgo is never opened any more, and everything stops when the script is called without any error message. The control "messagebox [info] [Here I am]" is not executed.

The puzzling problem is, that this happens only on the one Windows-11-desktop. where everything is being developped. But if I copy the KISS.lgo container (including the script) to a USB-drive and pase it to a windows 11 notebook and even to the Windows 10 notebooks used by the students, everything runs well and the failure isn't there.

Perhaps it has something to do with the fact, that the development machine is the first to be automatically updated by Microsoft. Perhaps something is deprecated or no longer supported by Microsoft. The same USB-stick that makes the notebooks of the students and our own notebook run, fails, when trying to run on the development machine.

This didn't happen some weeks ago, it came all of a sudden. Noting worked, and I see o workaround.

Do you have an idea, how I can solve this stunning problem?

[David Costanzo]

This line in your batch file in the one that starts the program:

"%~dp0\_local_FMSLogo_RO_\fmslogo.exe" -W 15360 -H 8640 -L _base_RO_\first.lgo

I expect that the rest is irrelevant.

This line runs a Logo program named _base_RO_\first.lgo, not base_RO_enter_.lgo as you later wrote. How does control flow get from first.lgo to base_RO_enter_.lgo?

Are you sure that you're running the exact same thing on your Windows 11 desktop as you are on all your other machines? Perhaps you inadvertently changed the batch script, or renamed the Logo program only on your Windows 11 desktop.

If I were to investigate this, I'd start by making the code that reproduces the problem as simple as possible. Can you get it down to just first.lgo running PRINT [here I am]? If so, upload that ZIP and I'll try to reproduce it on my Windows 11 desktop.

[Manfred Zindel]

"first.lgo" should be "enter.lgo. This mistake was made in the version I sent you and was the consequence of a mistake I made when experimenting in search of a workaround.

I now made a container, put it on a USB-drive and tried it from there on our development machine (where it failed in the known way) amd ten to our Windows-11-notebook, where it runs perfectly.
It is tis container which I zipped (still leaving half a Gigabyte)

Now I try to post it.

It doesn't work and tells me "Entity too large" - What cvan I do?

Perhaps I should try to make a very small enter.lgo-file, just to see, if it crashes, too.

[Manfred Zindel]

Well, I reduced the problem by creating a program that only consists of the starting script an a small file enter.lgo, which only says "Here I am". All the huge rest is gone. And what happens?
This time the failure is observed on all computers. "Here I am" is not shown.

Now I created a "micro_Container" (which is no container anymore) and zipped it. I send it now.

[David Costanzo]

I had to make a few adjustments, such as adding fmslogo.exe into the location where the .cmd expects to find it, but it worked for me on my Windows 11 Home desktop.

For troubleshooting, try removing the echo off from the .cmd script, starting a fresh "cmd.exe" prompt, change to the the directory with the .cmd script (with cd), and run the .cmd script from the prompt (instead of double-clicking on it). This will give you the output from the commands, one of which might be an error message.

Also, you write you don't see "Here I am" as the symptom of failure. Do you see the FMSLogo window?

[Manfred Zindel]

No,I don'see the FMSLogo window, only the scipt for a little moment, thereafter nothing.

[David Costanzo]

No,I don'see the FMSLogo window, only the scipt for a little moment, thereafter nothing.

It sounds Windows can't (or is refusing) to run fmslogo.exe. I think it's worth doing the troubleshooting steps I wrote earlier. The error message from Windows would be in that script window that flashes on the screen then disappears. I expect that the output shown in the cmd.exe window will indicate the problem.

[Manfred Zindel]

Thank you very much, David, for having a look at the problem.

Fact is, that the same program was the basis for everything we tested in schools, and it always worked for over two years, week by week for many interesting applications.. Now, without having changed it, it ceased working on one or the other Windows machine - that means, extracting and using the current root path failed.

And I wonder what might be the reason.

Well, what I'm going to do next is, to do some "modularization" for KISS.lgo, because it must be easy for normal programmers to keep it working, so that it can be easily maintained. It is written completely in FMSLogo and remains therefore downward compatible, even if FMSLogo should go to more platforms one day. I know, there is a lot of mighty competition (most interesting for the moment is Lua, not Python), but I still argue that it's worthwile taking a chance on Logo for reasons which have to do with Papert's and Solomon's "constgructionism" and that I recently discussed in a (German) paper and will have to discuss more sooner or later.

When I have completed the first "module" (it will take me only a few days, because I started it alteady), I'll zip it and send it to you or, if it's not small enough, I'll store it on our server, so that it can be dowloaded.

Wen I'm speaking of modules, I mean parts which have little dependencies from each other.

The first module completes the task, to provide a secure root path (the path where it starts) and store it as a buried gobal variable for the other parts that refer to it. This is crucial and somehow the soul of it all.

As soon as module one is completed, I'll send it to you. The task to solve is to get the root path and store it into the clipboard or another dedicated file somehow , so that FMSLodo can load it.

All my other trials so far failed, and I don't know, why this seems to depend on one or the other Windows-11-machine.

Well, these are my current plans, and I ask you to have a look at our module one to appear soon.

[Manfred Zindel]

It now seems as if clip.exe isn't found neither by the script nor by any other method. It exists in Windows\system32, but something may be wrong with the environment variable, and as I never was an administrator, I don't know how to repair things like these.

I had the seemingly simple idea, FMSLogo itself could provide the root path, as it really is part of the container. If I write POPDIR at the beginning, I get exactly the information I need, but only in the console, where I can neither store the path nor assign it to a variable. Then there exists the other problem that many operations on the path destroy the backslashes wich are mistaken for special characters. I cannot publish things that depend on so many unsafe conditions. I thought about workarounds, but none of them seems attractive enough to continue spending hours and days which I could use better. For a long time KIss.lgo seemed weöö strucured and safe and let me do interesting projects with it, but now I have many more doubts.

[Manfred Zindel]

Addendum: I found out that clip.exe is not only missing in this project, so it perhaps is the reason. All the other computers go on with KISS.lgo in a stable manner, and so, while the main computer is going to be repaired by somebody who is well trained as an administrator and knows the inside world of Windows, I'll switch to another computer which has no such problems and go on with my AI project in KISS.lgo, which can also be done in pure FSLogo. I hope it proves to be be successful.

[Manfred Zindel]

And here is the error message that flashed away all the time:

C:\Users\Manfred\Desktop\KISS 2026-06-09>_start_Super_Vision_8K.cmd

C:\Users\Manfred\Desktop\KISS 2026-06-09>echo C:\Users\Manfred\Desktop\KISS 2026-06-09 | clip
'clip' is not recognized as an internal or external command,
operable program or batch file.

[David Costanzo]

Manfred writes:

I had the seemingly simple idea, FMSLogo itself could provide the root path, as it really is part of the container.

You can use DLLCALL to call the win32 GetCurrentDirectoryW function.

; Calls the win32 function GetCurrentDirectoryW.
; Outputs the current working directory as a word.
; Outputs [] on error.
TO GETWORKINGDIRECTORY
    LOCAL [rval total_characters working_directory working_directory_length]

    DLLLOAD "kernel32.dll

    ; Call it with a NULL buffer to determine the required buffer size (in characters)
    MAKE "total_characters ITEM 1 (DLLCALL [L GetCurrentDirectoryW L 0 L 0] "kernel32.dll)
    IF :total_characters <> 0 [
        ; Read the directory name into a correctly-sized buffer.
        MAKE "rval (DLLCALL (LIST "L "GetCurrentDirectoryW "B :total_characters*2 "L :total_characters) "kernel32.dll)
        MAKE "working_directory_length ITEM 1 :rval
        MAKE "working_directory        ITEM 2 :rval
    ]

    (DLLFREE "kernel32.dll)

    ; Output [] on error.
    IF :total_characters = 0 [ OUTPUT [] ]

    ; Remove the NUL characters from the buffer
    OUTPUT FILTER [NOTEQUAL? CHAR 0 ? ] :working_directory
END

Similarly, you can call GetModuleFileNameW to get the full path of fmslogo.exe.

; Calls the win32 function GetModuleFileNameW.
; Outputs the full path of the module name on success.
; Outputs [] on error.
TO GETMODULEFILENAME :module
    LOCAL [rval]

    DllLoad "kernel32.dll

    ; Call it with a buffer size of MAX_PATH + 1 (adding 1 for the NUL terminator)
    MAKE "rval (DLLCALL (LIST "L "GetModuleFileNameW "L 261 "B 522 "L :module) "kernel32.dll)

    (DLLFREE "kernel32.dll)

    ; check for errors
    IF EQUAL? 0 ITEM 1 :rval [ OUTPUT [] ]

    ; Remove the NUL characters from the buffer
    OUTPUT FILTER [NOTEQUAL? CHAR 0 ? ] ITEM 2 :rval
END

Which you'd run like

SHOW GETMODULEFILENAME "fmslogo.exe

Manfred writes:

And here is the error message that flashed away all the time:

C:\Users\Manfred\Desktop\KISS 2026-06-09>_start_Super_Vision_8K.cmd

C:\Users\Manfred\Desktop\KISS 2026-06-09>echo C:\Users\Manfred\Desktop\KISS 2026-06-09 | clip
'clip' is not recognized as an internal or external command,
operable program or batch file.

That diagnoses the problem you see now where clip.exe is missing, but it doesn't explain the behavior you saw where FMSLogo didn't start. The Windows command interpreter will continue through failures, so fmslogo.exe should still have been started. The missing clip.exe may be a symptom of larger corruption. Hopefully your son will be able to figure out what went wrong (in addition to restoring the operating system) to prevent it from happening again.