China DOS Union

Object-Oriented Batch Language (Object Oriented Batch Language)

The text, code, and ideas in this article come from the following reference:
BATCH PROGRAMMING ELEMENTS (Dirk van Deun)
Chap 9: “Object Oriented Batch Language”
http://student.vub.ac.be/~dvandeun/batcoll.all
Special thanks to Dirk van Deun for his contribution!


　　I came across this article two years ago, but never paid it enough attention. A few days ago I suddenly dug it out again, and only then realized the value hidden in it. In it, the implementation of “object orientation” makes an important breakthrough in batch programming ideas, and its idea of using file structures to simulate data structures was also very enlightening to me.

　　The program uses file directories to simulate class libraries and object libraries, files to simulate the properties and methods owned by classes, and batch files to simulate object references, thus implementing the four major structures of OOP: classes, objects, properties, and methods, and thereby also implementing OOP features such as inheritance and overriding.

　　After thoroughly studying the program, I decided to make some modifications:

　　First, I rewrote all the code using internal commands, solving cross-platform portability as much as possible. At present, partial testing has been carried out and passed under MSDOS6.22/7.10 and the WindowsXP command line. My design goal is to make it run normally across the full MSDOS/ Win9x / WinNT's platform series.

　　Second, I changed the way objects are defined and called; that is, objects are defined directly by class name, and properties and methods are referenced by object name, making it more in line with OOP coding habits.

　　Third, I improved the scheme for using OOBL in batch files; although the original program was called OOBL, in fact it could only work at the command line and could not have all its code written into a batch file.

　　Fourth, I added public/private access attributes for properties and methods, making data encapsulation possible.

　　Finally, I made major changes to the strategy of loading variables before calling object methods and saving variables afterward. This change was unavoidable, because otherwise Dirk's original push/pop scheme would introduce the external program edlin.exe; but this new strategy also brings many problems: object data and class data are obviously duplicated, making data redundancy and space usage increasingly prominent.

　　So far, this is still a half-finished product, and it still has rather major defects. For example, in order to keep the structure clear, no error-handling mechanism was added; as for constructors for objects in the design and polymorphic method invocation, there is still no mature solution.

　　But my current state is very bad. I spent a full two weeks on it, yet progress was very slow. So I can only release this immature code. If anyone in the field is interested, you can study it and see. I hope someone can continue the unfinished work.

Below is a command-line example of OOBL:
E:\Batch\Test\OOBL>project work "work":class man "work":proprt Name "work":proprt FullName private "work":method setName set name=%1 set fullname=%2 %3 ^Z "work":method putName echo Name:%name%; FullName:%fullname% ^Z "work":class employee man "work":proprt salary private "work":method setSal set salary=%1 ^Z "work":method putSal echo Name:%name%; FullName:%fullname%; Salary:%salary%; ^Z "work":man John "work":John name=John "work":man fred "work":fred name=Fred "work":fred setName Fred Fred Ford "work":john putName Name:John; FullName: "work":fred putName Name:Fred; FullName:Fred Ford "work":employee bill "work":bill name=Bill "work":bill setSal $100000 "work":bill putSal Name:Bill; FullName:; Salary:$100000; "work":project :end Project is end! E:\Batch\Test\OOB>

A batch file example of OOBL is in the attachment


[ Last edited by willsort on 2005-8-4 at 19:47 ]

Hehe, not bad!

Quite a good idea for inspiring new ways of thinking.
But object orientation is mainly meant for large software development, or for writing programs that may be small but can conveniently call WIN API.
But this may be a bit mismatched with the situation of BATCH...
BATCH plus external commands only gives about 100 commands in total.
It's like bringing in an aircraft carrier and only being able to put it on an inland river... you can imagine how much use it would have... On the other hand, it would instead slow execution down,,

Also, to avoid rewriting code, BATCH already has CALL. It can also take parameters, which is a bit like functions...

Still, as pure research, that's another matter of course..

I think WIN scripts are quite good. The weak point of batch files is not program flow control, but data types and system function calls. It can only use internal and external commands, without system-level API calls. Sometimes you have to write a program for BATCH in order to complete work that actually isn't very complicated.
As for whether OOP should be considered only after the basic functions of BATCH are improved?
You also said in the article that external commands have to be used; that's because of this too, right?
Also, using the topology of hard disk directories to simulate the hierarchy between classes, I personally feel that is not very appropriate. At the very least, could you consider using a memory virtual disk? And directory structures have limitations too.

Actually, it would be better if DOS supported REXX.

I don't know too much about this, so please forgive me if I said anything wrong^^

[ Last edited by fdsiuha on 2005-8-20 at 21:54 ]

Re GOTOmsdos & fdsiuha:

Just as I said in the top post, this program is only a half-finished product in development, so naturally it has many defects and problems. But it introduces a new idea into batch programming, and that is naturally very helpful for broadening our thinking. And our task is to improve it step by step, so that it gradually reaches practical needs.

Re GOTOmsdos:

This is the first time I've heard that OOP is for conveniently calling Win API, and I don't know what that is based on.

As for the problem of there being few batch commands, this is how I understand it: all languages operate through basic syntax keywords together with support libraries. C has only a little over a dozen keywords too; everything else depends on functions and macros in libraries. And batch keywords (special command keywords) are also only a little over a dozen, while its support library is all executable programs under DOS. Of course, many programs do not have very good interfaces.

And the implementation of OOP is not only for avoiding code rewriting; it also has many other characteristics, such as the data encapsulation I mentioned above.

Re fdsiuha:

Win scripts are good, but they are not batch files. Although they are called “batch files under windows,” they are another kind of script. REXX is the same. They have many advantages and can easily complete many tasks that batch files find difficult.

But we can develop and strengthen batch files in every possible direction. The basic functions of batch files do need improvement, such as variable types (though most of the time I am satisfied with this Basic-like generic design), error handling (I have already done some work on this), text processing (I used debug and edlin to make some simple implementations), system calls, and referencing external support libraries (this is already close to maturity).

As for a memory virtual disk, that is still not within the scope of what we can consider now, because it still cannot become large enough to affect system performance. When this problem becomes prominent enough that we can no longer tolerate it, it will not be too late to discuss it then.

This is the first time I've heard that OOP is for conveniently calling Win API, and I don't know what that is based on.

Oh, what I said was mainly aimed at the situation of writing WIN programs; of course I didn't mean all of OOP..
Also, the main idea of OOP is not encapsulation, but first making reusable classes so they can be called. That's why there are class libraries. For WIN, there is ready-made MFC, so when writing programs you call them.
Conversely, without class invocation, OOP has no meaning..
But you need a large number of functions before encapsulation becomes necessary..
DOS BATCH doesn't have that.. Even if some function-like small blocks can be made, the quantity is hard to scale up..

I wonder whether other scripting languages involve classes? For example UNIX SHELL and so on, which are much richer than DOS BATCH...

[ Last edited by GOTOmsdos on 2005-8-19 at 13:15 ]

This...
it's better to use a real scripting language like perl
instead

Re GOTOmsdos:

It seems, brother, that you still have not understood my original meaning above.

In OOP, data encapsulation and reusability are equally important features; there is no distinction of which comes first. Comparatively speaking, the innovativeness of OOP's data encapsulation is somewhat stronger, because the reusability of functions in procedural programming (POP) is not bad either.

As for the number of functions, I have already said that “function” is only a specialized term in high-level languages. In a broad sense, it refers to the runtime support library. This is similar to the standard library of C++, the MFC of VS, the VCL of Delphi, and the J2SDK of Java. The runtime library of batch files consists of all the internal and external commands of the platform it runs on, all third-party programs, tools, and software (whether command-line programs or not), and all code and programs that batch files can call directly or indirectly. Of course, their interfaces may not necessarily be standard or friendly, and that is precisely what shows the necessity of encapsulation.

API calls can be made with the rundll32 command

These past few days I've been thinking that if a batch file is made too complex, that's a case of losing sight of the essentials. Simply doing “technology for technology's sake” has no practical value. Maybe GOTOmsdos was thinking along those lines too. Fully implementing OOP in existing batch files and internal commands would not bring benefits to ordinary users; on the contrary, it would make this kind of “secondary development” batch file hard to understand, let alone practical.

The advantage of batch files is that every line is an internal command / batch command, or an external command / application program. That way, as long as someone is somewhat familiar with DOS and uses certain commands fairly often, they can use batch files. No need to learn data structures, no need to understand OOP, and no need to learn a specific language.

Another advantage is that text is easy to modify, flexible, and convenient. Ordinary languages need a compiler or interpreter to run (COMMAND.com here is equivalent to an interpreter). Why shouldn't I just casually use some OOP language, all of which have the ability to call SHELL command lines, to replace batch files? And their OOP features are all complete, and they are also easier to understand than DOS batch files.

Therefore I do not agree that OOP is a direction for the development of batch files, and batch files should not be made more complex. But I absolutely do not mean that the OP's idea is bad. As a vehicle for studying and discussing the implementation of OOP, it is indeed worth researching. But the object of study is not batch files themselves, but OOP. It is like using self-hosting techniques to write the compiler for that language itself; in fact it does not have much practical value, but at least it can prove that such a thing is feasible.

PS: If DOS internally supported structured and object-oriented batch files, that would also be good and possible, but the COMMAND.COM file would need to gain a bit of “weight,” and the system overhead would also be a bit larger.

[ Last edited by fdsiuha on 2005-8-20 at 22:48 ]

Re fdsiuha:

Two years ago, my thinking was the same as yours — “batch files should not be made more complex.” Because simplicity and ease of use are the greatest advantages of batch files, just like DOS, the host platform they live on. So I did not pay much attention to the reference mentioned in the top post.

But now my thinking has changed somewhat — “batch files should not be made overly complex when there is no need.” Because over these two years my horizons have broadened. I have discovered many batch programs of considerable complexity, and I have also written some myself. As the saying goes, “what exists is reasonable”; whether it should or should not exist, it has already appeared.

Nowadays, it is difficult to say that DOS still has room to survive simply because of its “simplicity” — many users are already complaining, “Why is DOS so hard to learn?!” From another angle, it may itself be simple, in that its size is far smaller than comparable systems like Windows and Linux; however, the scale of difficulty is relative and shifting. Structural simplicity does not mean ease of use. For Windows to achieve a light mouse click, the price paid is a huge increase in size and performance consumption.

The phrase "Complex makes simple" has considerable validity. So in order to make batch files simple, it is necessary to do some complex work. Just as Java, in order to simplify object recycling, adopted the quite costly automatic garbage collection mechanism. Shifting complexity away from the user and onto the producer is an inevitable trend.

Doesn't your idea about DOS internally supporting OOP have a similar motivation?

Such a good thread shouldn't sink. Actually Microsoft's idea was to use WSH to replace bat, but vbs wasn't command-oriented enough, so later they also came out with PowerShell with reference to UNIX. There are too many new technologies; what matters is the ideas behind them.

willsort has already reached a truly masterful level, bumping the thread again in remembrance

[ Last edited by electronixtar on 2006-10-13 at 23:51 ]

This is another innovation and step forward :)
Huge bump!!!

Bump～～
This “@echo %dbg% off” is really interesting. When you want to debug, you don't even need to modify the batch file anymore :)

:: Sample.bat - Sample of OOBL :: Will Sort - 2005-7-31 @echo %dbg% off call project Work .....


This method is nice～：）
Set dbg=on　，
then after entering just this one line, running any batch file with a command like @echo %dbg% off will first execute the %dbg% parameter before it, haha......
Bump～

C:\TEMP\Oop>set dbg=on C:\TEMP\Oop>project.bat MyProj on off C:\TEMP\Oop>if "MyProj" == ":end" goto proje C:\TEMP\Oop>prompt "MyProj": "MyProj":md MyProj

And this prompt really gives people a bit of the feeling of entering the dot prompt era of Dbase,
as if you're really interactively entering commands in a development environment!

[ Last edited by redtek on 2006-10-14 at 01:11 ]

Bump~~~ Didn't expect batch files could be object-oriented too...