Local LLM - can WB HTTP perform it

[spl]

Figured before I got dis'd from the previous tangent I posted on a previous thread, did want to note a local LLM could add as a bot. Now the simple PS script below implements a request. I think in WB 64-bit could be done with my STD-OUT function, or re-written as HTTP Request. It does require Ollama to be installed [ setup: from https://ollama.com/download],

Code Select Expand

$body = @{
 model = "llama3.1"
 prompt = "Is Winbatch an Important Language to learn?"
 stream = $false
} | ConvertTo-Json -Depth 10 -Compress

# Send the POST request
$results = Invoke-RestMethod -Uri "http://localhost:11434/api/generate" -Method Post -ContentType "application/json" -Body $body
$results.response

and get....

Code Select Expand

WinBatch! A niche programming language that's still around, but its importance and relevance have evolved over the years.

WinBatch is a scripting language developed by Wilson WindowWare (WWWW) in 1990. Its primary focus was on automating Windows tasks, providing a way to write sc
ripts that interact with the operating system, applications, and files. WinBatch's strengths lie in:

1. **Automation**: Scripting repetitive tasks, like file management, data import/export, or system configuration.
2. **GUI interaction**: Automating interactions with graphical user interfaces (GUIs), such as clicking buttons, filling forms, and sending keys.
3. **System integration**: Interfacing with Windows APIs to access hardware, network resources, and other OS features.

While WinBatch is still maintained by its developers, its importance has diminished somewhat since its peak in the late 1990s and early 2000s. Several factors
 contribute to this:

1. **Microsoft's scripting tools**: Microsoft released various scripting languages (e.g., Windows Script Host (WSH), PowerShell) that provide similar function
ality.
2. **Rise of automation frameworks**: Tools like AutoIT, PyAutoGUI, and Robot Framework offer more comprehensive and modern alternatives for automating GUI in
teractions and system tasks.
3. **Shift to other programming languages**: As software development has become increasingly complex, developers have moved towards more versatile and widely-
used languages (e.g., Python, JavaScript) that can handle a broader range of tasks.

However, there are still scenarios where WinBatch might be the preferred choice:

1. **Legacy system maintenance**: Organizations with existing WinBatch scripts may prefer to continue using them due to familiarity and investment in custom s
olutions.
2. **High-speed automation**: For certain tasks, like rapid data processing or high-volume file manipulation, WinBatch's native Windows API access can still o
ffer performance benefits.
3. **Specific business needs**: Some industries (e.g., financial services, healthcare) may have unique requirements that make WinBatch a suitable choice for a
utomating specific tasks.

To determine whether learning WinBatch is important to you, ask yourself:
* Do I need to automate Windows-specific tasks or interact with legacy systems?
* Am I already familiar with programming concepts and looking for an alternative scripting language?
* Are there specific industry or business requirements that make WinBatch a suitable choice?

If the answer is yes, then learning WinBatch might be worth considering. However, if you're new to programming, it's essential to weigh the trade-offs against
 more widely-used languages and frameworks that can provide greater flexibility and career opportunities.

then change the promtp to:
 prompt = "Show Winbatch language code to list all running processes?"

and get

Code Select Expand

Here is an example of how you can use WinBatch (a scripting language for automating Windows) to list all running processes:
```winbatch
Procedure ListRunningProcesses()
  Local p,h,procName,procID

  ; Get a handle to the process list
  h = OpenProcess(0x0400, FALSE, 0)

  If h > 0 Then
    ; Read the number of processes
    ReadProcessMemory(h, 0, @p, 4)
    procCount = Dword(p)

    ; Loop through each process and print its details
    For i = 1 To procCount
      ; Get a pointer to the current process structure
      ReadProcessMemory(h, (i * 28) + 0, @p, 28)

      ; Extract the process name and ID
      procName = StrPtr(Ptr(p+4))
      procID   = Dword(Ptr(p+12))

      ; Print the process details
      MsgBox "Process #", i, ":", procName, procID

    Next i
  EndIf

  ; Clean up
  CloseHandle(h)
End Procedure

ListRunningProcesses()
```
Let me explain what's happening in this code:

1. We open a handle to the `NTDLL.DLL` module using `OpenProcess`, which allows us to access the process list.
2. We read the number of processes from the process list using `ReadProcessMemory`.
3. We loop through each process, reading its details (name and ID) into memory using `ReadProcessMemory`.
4. We extract the process name by converting a pointer to a string using `StrPtr` and `Ptr`.
5. We display each process's details in a message box.
6. Finally, we clean up by closing the handle to the process list.

Note: This code assumes that you have administrative privileges on your system, as it requires access to kernel-mode memory. If you don't have admin rights, t
his code may not work.

Also, keep in mind that listing all running processes can be a resource-intensive operation and may take some time to complete.

[bottomleypotts]

Does the winbatch code work?

[td]

Figured before I got dis'd from the previous tangent I posted on a previous thread, did want to note a local LLM could add as a bot. Now the simple PS script below implements a request. I think in WB 64-bit could be done with my STD-OUT function, or re-written as HTTP Request. It does require Ollama to be installed [ setup: from https://ollama.com/download],


then change the promtp to:
 prompt = "Show Winbatch language code to list all running processes?"
...

Played with ollam and local models myself. I like to run local models to sidestep techbro servallence. I run the servicer as a sub-process of a WinBatch service for convenience. Which model or models have you used?

[td]

Should add that there is another approach to all this. I have a WIL extender that loads models directly into process memory without the Ollama server and lets me tweak model parameters. It is interesting but not very useful for most users due to the hardware requirements. For example, I have a four terabyte hard drive to store models, but could use more system memory and should install CUDA drivers for the system's NVIDIA GPU.

And yes, some models do not know WIL at all, and others know just enough to cough up usable scripts for a few simple tasks.

[spl]

Thanks Tony. It is fun to do with PS, but WB might be able to give it a go for the curious. I translated the PS => WB. The script header notes requirements and as written will fail as Body elements are passed as type string. I suggested the body may need to be an array or map, not sure. But if anyone wants to play, fix, or improve.

Code Select Expand

;TEST prompt with Local LLM
;Requires Ollama server be installed
;once installed run 'ollama pull llama3.1' from terminal to ensure model
;should error that cannot marshall Body element
;may need to created as a map or array
;best run under WB 64-bit
;Stan Littlefield 5/4/2026
;========================================================================================================================
objHttp=CreateObject("Msxml2.XMLHTTP.6.0") ;or use WinHttp.WinHttpRequest.5.1")
URL = "http://localhost:11434/api/generate"  
objHttp.open("POST",URL,"False") 
objHttp.SetRequestHeader("Accept", "application/json")
objHttp.SetRequestHeader("ContentType", "application/json")    
Body = `{"model":"llama3.1","prompt":["Show Winbatch language code to list all running processes"]}`
objHttp.Send(body)
while objHttp.readyState != 4 
   objHttp.WaitForResponse(1000)
endwhile
;Terminate(objHttp.Status != 200,"LLM Prompt", "Request failed")

strResponse=objHttp.responseText                  
Message("Response",strResponse)  ;should show error
objHttp=0
;FilePutW("C:\temp\strResponse.txt", strResponse)
exit
;========================================================================================================================

[td]

I have changed my system to using llama.cpp's llama-server.exe. I think that Ollama is built on the llama.cpp open source code base. Anyway, if I make a small change to your script so the URL conforms to llama's REST API, I get a server response. Unfortunately, the model I selected does not know WinBatch syntax, so it returns an example in Java...

[spl]

I played around with some prompts containing 'Winbatch' or spelling as 'Wnbatch'. The llama3.1 model would return python or autoit code. Added the Gemma4 manifest and my Surface Pro ran out of disk space. I'm thinking about trying the WB code as a CLR HTTWebRequest and using the streaming option with GetBytes() to pass along the body... but put that on hold. 

[td]

So many models and so little time. When I encounter an open model that has some understanding of WinBath's WIL, I will post the name here.

[td]

I had a chance to use llama-server.exe pointed at different Hugging Face models, so I didn't have to perform muilti gigabyte downloads. I found some that did a reasonable job of calling WIL's built in functions to complete tasks, but they all seem to stumble on WIL subroutine and function syntax. It makes some sense since the #define... #end.. syntax is somewhat unique.

[spl]

So many models and so little time. When I encounter an open model that has some understanding of WinBath's WIL, I will post the name here.

Copilot doesn't do a bad job. I've seen it do Wil code, but often uses a function that doesn't exist

[td]

That mythical do what I am thinking function. Never did completely figure out the mind reading part of that one...

I normally don't use Copilot and have uninstalled it from my workstation. I hadn't even considered it because of the similarities to OpenAI's chatbot. I assume Copilot and ChatGPT have diverged significantly, so I will try Copilot on a virtual machine that is running an out-of-the-box version of Windows.   

[JTaylor]

For some reason, this reminds me of years ago when I was asked to fix a user interface so that it would only accept correct information.

Jim

[td]

I need to correct something I stated earlier. Claude Code can produce a syntactically correct WIL UDF if the phrase "create a user defined function" is used with the description of its purpose. However, the fantom function problem (FFP?) remains.

[spl]

I need to correct something I stated earlier. Claude Code can produce a syntactically correct WIL UDF if the phrase "create a user defined function" is used with the description of its purpose. However, the fantom function problem (FFP?) remains.

Latest update:
Ollama 0.23 now supports Claude Desktop's built-in third party inference.
 
This allows all models from Ollama's Cloud to be available for use within Claude Cowork and Claude Code from Claude Desktop

[kdmoyers]

<<However, the fantom function problem (FFP?) remains.>>

Yup, that's my main complaint with the llms performance. Claude seems to create hallucination-functions like crazy with Winbatch and with AutoHotKey.  The problem seems much rarer with MS SQL, javascript, css, C#.  I guess I was hoping that if I could give it better access to official doc, that behavior would decrease.

Perhaps it's a question of "signal strength".  Like, because winbatch looks like other languages, but is not talked about as much, its signal gets mixed up with other languages?  I have no idea what I'm saying.

Thank goodness its so dang good with SQL, where most of my work is these days. 

The kids are scripting in Python, which Claude also seems to do well with.

[td]

I think the reason machine learning models perform better with some programming languages than others is more than signal strength. The underlying reason is in part the result of human bias. I noticed in the early days that ChatGPT was much more adept at Python than other scripting/programming languages. It is not a coincidence since Python is the lingua franca of AI bros. I assume that MSFT has made sure that CoPilot is adept at writing PowerShell scripts. That is just an uneducated guess since I don't use either one with any frequency.

I don't use AI to write code. I use it more as a glorified search engine to find information about algorithms that may provide a solution to a knotty programming challenge. There are several reasons for this. One is that I enjoy writing code, so why let the machines have all the fun? Another is the time spent fine tuning prompts to produce an acceptable result. It doesn't increase productivity all that much. Also, the quality of the responses often declines as the complexity of the task increases.

I am interested in Agentic AI to handle some of the more mindless tasks involved in software development, but that is still a work in progress.

[spl]

This thread could end up being too much fun. But from my perspective, currently (as Tony indicated) AI produces the most accurate code for Python or Powershell, with the standard models. Below I asked llama3.1 two questions:

"Write Winbatch code to create a map for US states/cities"

"Write Winbatch code to create an array for US states/cities"

The results are below and not anywhere answering the question. But in the old days of this board had a member post something like "I am new to Winbatch, and trying to figure out maps. Can I create a map for all states and capitals?". I'm sure they might have received an RFM, but probably several suggestions with code. That was the way this board, and perhaps others, used to work... but for reading this far... AI

Code Select Expand

Here is an example of a WinBatch UDF (User Defined Function) that creates a map array:
```
; map_array_udf.wb

; Create a Map Array UDF
MapArrayCreate PROC
  LOCAL hmap := MapCreate()
  LOCAL i, j
  LOCAL arr[10][10]

  ; Example: create a 10x10 map array with default values of 0
  FOR i := 1 TO 10
    FOR j := 1 TO 10
      MAP_SET(hmap, i, j, 0)
    NEXT
  NEXT

  RETURN hmap
ENDPROC

; Example usage:
MAIN
  LOCAL hmap := MapArrayCreate()
  LOCAL i, j

  ; Print the map array to the console
  FOR i := 1 TO 10
    FOR j := 1 TO 10
      ConsoleWriteAt("%d ", MAP_GET(hmap, i, j))
    NEXT
    ConsoleWriteAt("\n")
  NEXT

  MAP_DELETE(hmap)
ENDMAIN
```
This UDF creates a map array called `hmap` with dimensions 10x10, initialized to 0. The `MAP_SET` and `MAP_GET` functions are used to set and get values in the map array.

The example usage at the end demonstrates how to create an instance of the map array using the `MapArrayCreate` function, print its contents to the console using `ConsoleWriteA
t`, and then delete the map array using `MAP_DELETE`.

Note that this is just a simple example, and you can customize the UDF to suit your specific needs.

To use this UDF in your WinBatch program, simply copy the code into a file with a `.wb` extension (e.g. `map_array_udf.wb`) and then include it in your program using the `#incl
ude` directive:
```
#include "map_array_udf.wb"

Code Select Expand

Below is a simple example of how you might create and populate an array with the names of some U.S. states and cities in WinBatch (also known as "WinBatch" but its actual name 
is "ScriptBasic" when it's used within its IDE, though many people refer to it simply by its original company name). This example uses a two-dimensional array where each row re
presents an item (state or city) and the columns represent specific data about that item.

```batch
; Declare an array with 10 rows and 2 columns.
ARRAY wStates[10, 2]
wStates["Name"] = ["Alabama", "Alaska", "Arizona", "Arkansas", "California", "Colorado", "Connecticut", "Delaware", "Florida", "Georgia"]
wStates["Capital"] = ["Montgomery", "Juneau", "Phoenix", "Little Rock", "Sacramento", "Denver", "Hartford", "Dover", "Tallahassee", "Atlanta"]

; Display the array.
FOR wI = 0 TO 9
   PRINT wI, "| Name: ", wStates[wI, "Name"], " | Capital: ", wStates[wI, "Capital"]
NEXT wI

; Note on array indices:
; - In WinBatch, arrays are 0-based. That means the first element in a declared array has an index of 0.
; - The number in brackets after the array name (`[10, 2]`) indicates that there will be 10 rows (or 10 elements) and two columns.
```

This code snippet does the following:

1. Declares an array named `wStates` with dimensions [10, 2], which means it can hold up to 10 items across two categories (states and capitals).
2. Populates the first column of the array with the names of U.S. states.
3. Populates the second column of the array with their respective capitals.
4. Displays each item in the array along with its index using a `FOR` loop.

Remember, this is just a basic example to demonstrate how arrays can be used in WinBatch. The actual implementation may vary based on your specific requirements and needs.

[td]

I finally got around to testing out Copilot after struggling with a VM update - don't ask... Anyway, here is the result:

Code Select Expand

;---------------------------------------------------------
; Function: CountFiles
; Purpose : Returns the number of files in a folder
; Params  : folderPath – full path to the directory
;---------------------------------------------------------
#DefineFunction CountFiles( folderPath )

   ; Ensure folder ends with a backslash
   If StrSub(folderPath, StrLen(folderPath), 1) != "\"
      folderPath = folderPath : "\"
   EndIf

   ; Get list of files (not folders)
   fileList = FileItemize( folderPath : "*.*" )

   ; Count items
   fileCount = ItemCount( fileList, @TAB )

   Return fileCount

#EndFunction


folder = "C:\Temp"
count = CountFiles( folder )
Message("File Count", "Files in folder: " : count)

exit

I have been using the same simple prompt for every model queried. Copilot is the first one to produce a working response.