DOS in DOS with VBDOS 1.0

[LiwisJames]

Hello everyone, I'm still working with old technologies and using VBDOS I haven't figured out yet how to use PICTUREBOX but I've made progress in reading and writing text manually, but now I have an idea of multitasking in DOS that's right, something unprecedented how the concept works Well the idea is to copy the concept of opening the command inside windows when you create several windows since windows 3.11 it is very simple in fact the project will have a new command button and ready your vbdos program will create a new window within the same program with the command embedded in your body. It will be exactly like the one below:



I call this concept DOS in DOS because you will open several DOS windows, being able to execute whatever you want inside each one while editing the other one, this will make the development a lot easier the idea is not to be like windows or to have several options, it's actually several MSDOS programs that could be started through the console, so I could use several cool things like opening vbdos in one tab and in the other tab listening to music with some program for that, while running a third application, of course I'm aware of the limits and there will be applications that will be run at most in 2, but for small programs it is quite functional.


I need to consider a few things and as you guys have more experience than me because you lived at the time, I need a development base, let's go:

First question, how does command.exe work inside windows 3.11 that it opens in an MSWIN window the idea is to take advantage of this concept and recreate it in VBDOS.

I've already made several VBDOS forms and it's possible to create an MDI, I found this option within VBDOS but I don't know how to use maybe some way of calling the command to work.

The process of playing an application inside another requires what in practice, through frameworks I have the understanding, but I would like to know a more robust logic that would be the case of VBDOS.

Has anyone done something similar to run some vbdos application inside another one? when I use the RUN command it works, but it closes one and opens another the idea would be to run together, but instead of just vbdos any msdos, any ideas to cover?

With these concepts maybe this project would be possible and with that it would help in hobbies of several lovers like me of MSDOS.

[Niya]

You're asking this question in the wrong forum. You need to find a forum that deals with the development of operating systems, perhaps the Linux community or projects like ReactOS would have members that could help with this. The reason I say this is because what you're asking requires a different type of expertise to what you would typically find here. If I understand you correctly, you want to imitate the way Windows 3.1 can load the MS-DOS shell as a process that participates correctly in the pre-emptive multi-tasking world of Windows. What you're really asking is how to load and execute code on the CPU on your terms which is something that operating system shells are typically responsible for. People who have experience writing operating systems would know how.

At the very least, I'd ask this question in an assembly language forum. There's always a member or two on assembly language forums that have a deep understanding of how operating systems create and execute processes in the CPU.

[Eduardo-]

...and... no doubt he is in the right place, but... asking questions about "VBDOS 1.0" is like taking the "and Earlier" feature of the forum a bit far.
My first VB was 3.0 so I can't help. And I don't think I would be able to help much regarding VB 3/4/5 either, since I used them too long ago and I already forgot too many things.

Good luck with VB 1.0.
PS: perhaps if the OP could explain his motivation in working in such old stuff could find someone who gets interested in the same project/idea/hobby/museum_stuff

[passel]

Windows 3.1 wasn't preemptive multi-tasking. It was a DOS program that you ran that provided a graphical environment and allowed cooperative multi-tasking between applications written to voluntarily return processor control back to the Windows by following the protocols defined by the Windows APIs.

...
Good luck with VB 1.0.
...

It's not VB 1.0
VB 1.0 ran under Windows (Win 3.1 at the time). VBDOS 1.0 ran in DOS, no Windows involved.
VB on Windows continued (VB 2, 3,... 6), VB on DOS didn't, there was only Version 1.0.

My only experience with VBDOS was when someone unfamiliar with Visual Basic needed to write an application using it at work, so he order Visual Basic, through the purchasing department, and he received Visual Basic for DOS, not Visual Basic for Windows (which was version VB 3.0 at the time). So they had to order VB 3.0, and I took the opportunity to go ahead and install VB for DOS on a machine to check it out, as I had VB 1.0, 2.0 and 3.0 at home, but had never bothered with VBDOS (I believe that VB 1.0 and VB for DOS may have come out at pretty much the same time, although VB for DOS may have came out a bit after VB 1.0, emulating some of the VB 1.0 paradigm for DOS users..

MS-DOS was primarily character based, and as far as I know VBDOS lived within the confines of that character based environment so I don't know that it even supported a Picturebox type control. The standard IBM Extended character font had a lot of built in characters with vertical and horizontal and corner line segment characters that when properly selected and place adjacent to each other vertically and horizontally could draw rectangular boxes on the screen, and you could populate the interior of the rectangles with characters, having to be careful that you didn't clobber your borders with text characters.

VBDOS just encapsulated the maintenance of those rectangular areas, adding mouse support, and events, and designating some of the rectangles as buttons and others as textboxes, labels, etc... and providing z-order logic to determine which characters on the screen belonged to which "controls".
Being it was character based, the resolution was rather poor. A single button with a single line of text would require three rows of characters vertically out of your available screen space, a row of characters for the top line of the button, the line of characters for the text and a row of characters for the bottom line.

DOS was character based, it didn't provide a graphical environment. You could switch the graphic card to a graphic mode, and draw images and character in that graphical space, but I don't know that VBDOS supported that. That is what Windows provided, a graphical front end to DOS.

You are showing a Graphical representation of a DOS window in a Window's Window, which is supportable because Windows provides the graphical environment. Since DOS doesn't provide a graphical environment, how do you propose to have VBDOS support multiple VBDOS windows. There isn't much visual real estate available in the normal DOS character based environment. What you probably want, without windows, would require some other graphical based environment that would support virtual consoles, i.e. inventing a Windows Lite.

[Eduardo-]

Good stuff for History Channel.

[DataMiser]

I worked with VBDos quite a lot back in the day but when I open one of the projects now it looks totally foreign to me.
I'm not sure that what the OP is asking is even possible in VBDOS and really not sure how it would be of much use given that most systems built in the last 20+ years are not really DOS compatible.

[LiwisJames]

Yes VBOS has the PictureBox system, but I have never been able to use the picture box or upload any image, I discovered interesting things like the PCX 256 color image format a maximum approximate size of 400x400 of an image but I never used the control, yes MSDOS uses a poor artificial GDI system that formulates with drawings a window it covers the background with characters from the ASCII table and then makes use of the rectangular shapes of the VBJOS and creates a window with colors, however the windows and their events were really made similar to Windows 1.0 I can not remember where I saw, but he picked up the concept of the time and the base to simulate a program running on Windows without the need just to create a window base and form your application, Microsoft has A VBDOS 2.0 but has never been released for financial matters where the Windows program was more lucrative and already had Visual Basic 1.0 so they did not release this project so I can assemble windows and their refuses at the time, which came out more advantageous the company, however came out a beta of vbodos 2.0 on the internet between the 2000s that I think it would be difficult to find it currently so polluted internet and this bubble search.

[LiwisJames]

The DOS would be able to run another MSDOS inside him if a window was created where it could start or simulate the process, from the very own as an emulator of himself. Or call from behind. I would like to perform at least if it is not possible that any program inside my vbodos and then when that was closed, then the application returns, I only know the Run command of the VBDOS that starts another but closes the first.

I've tried some similar things How to create an MDI window, VBOS enables this option however I could never use because it would need a base or book I tried to find the guild to MSDOS msdos but the book is expensive and does not have PDF version It would not compensate for the effort and spent.

My experiment was as follows:

Create an executable with VBDOS, and depos executes it using the Run function, it worked however a does not call the other and yes it closes the previous and loads the next.

I looked for the MDI function to make the call or turn into child to call within another .exe, but without success.


If you had all right in these experiments and modifications with these two functions would be perfect because you could get a way to set the programs as a subroutine and executors generating within a GDI Form dynamic created autonomy.

[LiwisJames]

Yes true or not

[DataMiser]

Well if you want to spend your time on this then more power to you but to me the question is who would have a use for it? It has been ages since I even saw a computer running DOS. I doubt that there are many people out there still using it or that matter even have hardware that supports it.

[Niya]

or that matter even have hardware that supports it.

DOS is so extremely simply that it can exist today with hardware that is simulated entirely. The DOSBox emulator for example.

[DataMiser]

DOS is so extremely simply that it can exist today with hardware that is simulated entirely. The DOSBox emulator for example.

But that is not running DOS imo, it is running an emulator under Windows. You could use a VM as well but again is a bit different. I was referring to using DOS as the system OS which is what I assume the OP is referring to and that is a real problem on even remotely modern systems.