This is as far as I got.. It seems to display some question and waits for a key input.
Check if it's N, then it executes some dos command. If it was Y it seems to return from this subroutine.
8607,,,1 ; deactivate F7
11547,15475,22002,22002 ; clear pause flag # var1547 is the pause flag
1316,1629,1,1649 ; var1316 = displayPromptAndGetInput(loc: [29,16], numChars: 1, cursorLoc: [49,16])
3001,1316,3,30078 ; if var1316 == 'N'
11528,22052,22002,22002 ; var1528 = 5
9301,0,1528,1528 ; ??? put to data model, prompt1: var1528, prompt2: var1528
31568,10001,800,107 ; var1568 = tableTransfer(800, 10).item ?
8560,,,1568 ; execDOSCommand(var1568)
8550,210,, ; ??? Combination goto
3001,,, ; end if
3100,1316,3,30089 ; proceedIf var1316 == 'Y'
11547,15475,22002,22002 ; clear pause flag
3001,1316,3,30089 ; if var1316 == 'Y'
3001,1317,3,10000 ; and if len(var1317) == 0
8400,,, ; save address # for return
8550,700,801, ; ??? Combination goto
3001,,, ; end
9301,0,522,522 ; ??? put to data model, prompt1: var522, prompt2: var522
3000,1284,3,10001 ; if var1284 == -1
8500,,3, ; goto label3
8500,,5, ; goto label5
1547,,1,-2301 ; ??? pauseFlag = getInput(numChars: -2301?)
Whilst I genuflect and doff my metaphorical hat to you, O great nerd, how do you know this? Was this language wide-spread and used a lot in banking (?). Please can you tell us how you came to understand this arcana! What on _earth_ led to its longevity? Virtually any raw assembly code is easier to read (for me).
What on earth is going on with the commas? For example, the line
11528,22052,22002,22002 ; var1528 = 5
The only pert of this I can vaguely get is that the 11528 refers to a variable #1528. It's the only variable assignment in the above snippet, but 22002 appears several times, twice as the last argument. I don't quite get why; the two lines are doing very different things.
Enlighten us!
------- Edit -------
From the Esolang wiki (https://esolangs.org/wiki/BANCStar) it transpires that, for the example given above, we can actually understand the opcode above. BANCStar is fairly similar to an assembly language of the form (opcode, arg1, arg2, arg3) where not all opcodes require arguments (leading to blank commas) and the numerical form of each opcode is sometimes parsed characterwise (and sometimes not). So, for the 'add 5' example that the OP correctly provides above, the "rules" seem to be:
The most complicated type of instruction seems to be arithmetic instructions. Here, the first number is 10000+d, where d is the address of one of the 2000 variable cells ("prompts") as the destination operand.
The other three numbers are of the form (10v+p) or (22000+10n+p) where p is an operation code, v is a variable cell in the range [1, 2000], and n is a constant literal integer.
When a parameter is unneeded, it is usually set to 22002 (i.e. "add 0").
In this case, I think we're literally doing the following:
11528,
^variable 1528 =
2205
^ (int)5 is the argument of the forthcoming operation
2,
^ ... and that operation is "+"
22002,22002
^ +0, +0
But not everything is documented. I also found some GitHub page with more code. Maybe it’s fun to create something that can actually parse this.
According to that info, 22002 is add 0 (essentially noop). Not sure why all operands are required instead of leaving them blank.
The 22052 means set to 5.
Probably because Malbolge was kinda sorta expected to be written by humans.
BANCStar "code" is really IL/bytecode, it just happened to be ASCII bytecode (initially anyway, according to the wiki it became binary with BANCStar 10).
I guess the "program" makes sense as it was apparently supposed to be a 4GL (or is it 5GL?) where the entire thing would be designed through a UI:
> BANCStar actually came with a "screen generator" that was supposed to be used to construct applications. But the 5.1c version of the generator was so limited that experienced programmers soon began to pry off the covers and modify directly the intermediate code that the run-time module actually executed.
In that sense, they're basically editing the raw bytecode files, for something with less than great semantics but those semantics wouldn't really be visible / a concern if a generator program would be managing them.
I was wondering how on earth anything like this could've been developed - now it's making more sense. BANCstar probably was intended to be something like Visual Basic or Hypercard, where the bulk of the development was done using a high-level visual designer, but for whatever reason the suite ended up half-baked. Devs then get forced to use the intermediate language directly, and no budget is ever allocated to finish the product because they actually seem to be managing with the half-baked version just fine.
> and no budget is ever allocated to finish the product because they actually seem to be managing with the half-baked version just fine.
TFA talks about BANKStar 5.1c but the wikipedia article mentions that BANCStar 10 switched the screencode (bytecode) to binary, so it looks like the thing kept on trucking for a while.
And the programmer kept stretching the thing for purposes it was not really intended to (possibly because it was difficult to get approval for better techs), as reading between the line and other articles on the subject it looks like BancSTAR was really a glorified forms creator / manager, which makes some of the limitations make more sense e.g. 2000 labels, choices and fields in a single form (even across multiple screens) seems like a pretty generous limit at first glance.
> a three-ring binder called the Prompt File, stuffed with printouts of the dozens of tables in the system, and religiously updated anytime anyone changed anything of significance.
Letter variables? Luxury! One of the calculator had ops like STO, RCL, PAU, GTO, GSB and some numbered "cells", where you could store the result of the calculation.
The other had ops like '74' which were coordinates of the key which activated the given function.
Getting the full screen of the ZX Spectrum surely spoiled me :)
Geometrical proofs could be construed as such, even with some propositional logic given that someone comes up with a solid, universal way of expressing it (cf. The Golden Record)
Well, as a DBA, I periodically use a 3rd party tool to print out the schema. It's mainly for new hires to learn from.
But sometimes I'll flip through it and notice:
- mis-spelled table names, usually duplicate tables
- missing FKs
- missing unique keys, most commonly for early RoR apps
- developer-specific EAV tables with 1 row.
The benefit always outweighs the dead trees, but printing once a year is typical. Back in the day, more frequenctly on 25-line terminals where there was too much scrolling.
User redis_mlc has been shadowbanned for eight months which is an abhorrent practice. He is a prolific contributor, but most readers will never see his comments. Occasionally, a reader with showdead:yes in the options and sufficient karma will "vouch" a post back into general visibility.
I made far worse things than this in the past for intermediate files (kind of a VM, but in the past we made these to 'obfuscate' dynamic code, not for performance or other reasons). For instance, we made a lot of software for DOS/Windows used by (most) schools in my country and my uncle, who made the content, was rolling out versions for different subjects quite fast, so I made this intermediate format which came from content with 'tags' (like [IF x<y THEN ...] inside the content) which did not look unlike what is in this article; indeed also representing all text and images are integers. This was done to make it unreadable for the average person who tried. Then, based on the school license key, that file was encrypted (badly) to make it even harder.
I suppose there were and are many of these kinds of things going around in save files etc. You just would never predict or hope that people go and reverse engineer it to write directly in it.
Back in the late nineties, I worked with a software called Origin. It had a BASIC like programming language where variable names consisted of single letters. If you now think 26 variable names should be enough: Some letters, like X and Y, had special predefined meaning, and you couldn't change that. If you used them, you encountered strange behavior, like values changing behind your back. To add insult to injury I could never find documentation about which variables were special, so I stuck with the few I knew were safe, which were not many...
More like, one company created a drag-and-drop editor for their enterprise software, and the customer decided to edit the byte code it output.
It’s a little unfair that people are referring to this as a bad programming language where it’s actually effectively a save-file that has been reverse engineered to edit it beyond its original scope and functionality.
Compiled java bytecode is also not the best programming language, albeit admittedly much better than this!
I would have agreed with you if it weren’t for the other limitations, like the hard limit of 2000 variables and constants and lack of scoping forcing larger projects to reuse variables in multiple unrelated places.
The limit doesn't seem unreasonable given the intended purpose: very likely if someone ran into the limit using the "screen generator" (and was paying for support) it could be fixed with a simple recompile of the interpreter.
Similarly I don't think there's anything wrong with generated code not having a notion of scope.
Agreed - in fact I bet the original creators thought they were being generous allowing for 2000 variables for their gui editor!
Vendor Engineers: “Who would possibly need more than 2000 variables to make a few custom screens in our new drag and drop screen editor feature?”
Customer Engineers: “Hey we can exploit this new custom screen editor to inject our own arbitrary code! Why have they only allowed for 2000 variables? Idiots!”
You might be right but your argument rests on an awful lot of assumptions that weren’t detailed in the article.
It’s just as likely it was intended to scale the way it had and it was just poorly implemented from the outset. I’ve seen this happen plenty of times in the past where an extremely rudimentary POC is rushed into production and the official workaround is a scary chain of kludges. It was especially common in the era this BANCStar originates because compute time was expensive so it was often cheaper to code by hand and then hire typists who’d input your code and compile it, passing you a print out of any errors raised. Starting again from scratch if your basic premise sucked often wasn’t an option. Man do I not miss those days.
> They decided to do that because the drag-and-drop editor was unfit for purpose.
Unfit for their purpose - it probably satisfied the purpose that BANCStar was selling it for.
It sounds like they just realised that this feature of BANCStar would let them inject their own arbitrary code to allow deeper modification of the system than what was intended, which was not within the scope of the original feature.
I know this is unfair and untrue, and I am ignorant in the history of programming languages, and ignorant in the history of bank infrastructure, but ...
My actual first thought was that this was a language designed by someone who didn't know that programming languages exist.
My second actual thought, after reading over my first actual thought, was that it could be a language designed by someone who decided to take that programming languages assignment from back in school and this time do it right.
Speaking of bank infrastructure, where can I find more information about it? I remember an HN thread from a while ago that led me into a rabbit hole about how ACH works and it was fascinating. I’m not even sure which keywords to search that would get me started…
Besides that article's subject, it has enough links to keep you busy for months. Be sure to read the "Security" section.
"Banking" is a huge subject. If you really want to learn (part of) it, best would be to find an area that interests you, and work in it. That's one of the best parts of programming, it's not really about programming, it's about the industries that use it.
As for "key words," I think better is to follow links, and soak in any keywords that gradually come from what you find that's interesting.
Back in the day there was a business graphics program called Zenographics Mirage. Think a very primitive PowerPoint that you could use to print to actual slides, as in the things you loaded into a slide projector.
Mirage had three major components: Chart, Ego, and Autumn. Chart was a menu-driven business chart package. Bar charts, pie charts, bullet lists, standard stuff. Notably, it made it very easy to add gradients, which Mirage called "sweeps", to your chart, because it was the style at the time. Ego stood for "Edit Graphic Objects" and was menu- or command-driven, like AutoCAD, and served as a general vector graphics editor. I forgot what Autumn did, something about importing data? Like from spreadsheets and stuff?
One of the features of Ego was that it could be scripted. Zenographics provided some example scripts, and some of them had really odd commands, just DO with numbers after them.
It turns out that "Mirage" was the runtime and abstract machine, and Chart, Ego, and Autumn were applications running on it. The numbers in the DO commands were opcodes for their VM's instruction set, which was called "MAD" for Mirage Application Development. MAD had primitives for doing stuff like picking stuff from the screen with the mouse, menus, and so on. Mirage could be put into a debug mode that flashed the opcodes as they were being executed. Using the information that provided, as well as the numbers from the example scripts, I was able to figure out what some of the opcodes did and use that to write new commands. Like I added a rectangle command to Ego that worked much like the built-in rectangle command, but it created a rectangle that could be rotated. (It created a four-segment polyline rather than a rectangle object defined by diagonally opposite corners.)
Mirage was a fascinating program but it is little known today. Zenographics got out of the application software business to focus on printer drivers a long time ago. Today they are a subsidiary of Marvell, the chip company.
It would be a weekend project in this day and age to write a simple human readable to number compiler. Why were the developers so willing to continue working without improving their toolset?
For one they were in their day and age, not the one we are in now. Also, using a toolset means throwing away everything you already have and starting over. Probably not an option in this kind of ‘enterprise’ system.
When I got my Bachelor's degree, we had a microprocessor lab that had a microprocessor kit with a keyboard that had hex numbers 0-9,A-F, and a few control keys such as load, reset, etc. To program the device, we wrote the program in assembly, looked up the corresponding hex opcodes and operands and basically did an assembler's job. The result was a bunch of hex codes that we loaded and executed. I'm guessing these codes are similar, and there's a lookup table of codes somewhere?
If anyone has to use this, why not simply use assembly? Learnt COBOL and S360 Assembly which are obviously not great but widely used by almost all banks. COBOL is way too chatty, S360 Assembly is just like any other assembly language. But even S360 Assembly is much more readable than this. So it would be incredible that someone really completed a core banking application with it.
> Everything in the system is global. New projects always started off with the programmer searching for a handful of working storage numbers that could be "borrowed" long enough to complete the calculation, then restored to their original values before the rightful owner noticed that they were gone.
