Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Martin Vieregg

Pages: 1 ... 6 7 [8] 9 10 ... 17
106
Programming / Shared Memory correct usage
« on: March 21, 2020, 11:42:28 am »
I want to use one Shared Memory in both directions. Samples in the internet are poor.

In the server, I wrote:

rc := DosAllocSharedMem(SharedMem, NULL, 4096/*smaller has no effect*/, PAG_WRITE | PAG_READ | PAG_COMMIT | OBJ_GETTABLE);


SharedMem is an untyped pointer.

I transfer the pointer value via commandline parameter to the client.

The pointer value is hold in ulong4.

In the client, I wrote:

      SharedMem = (VOID*) ulong4;
      SharedMem2 = (VOID*) (ulong4+8);
      rc = DosGetSharedMem(SharedMem, PAG_READ | PAG_WRITE);
      PSharedULONG = (PULONG) SharedMem;
      PSharedULONG2 = (PULONG) SharedMem2;

     
I can write the values in the server and read the values in the client, but not reverse (crash). I wrote in the client:

    *PSharedULONG2 = 2;
    //Now it crashes. PSharedULONG also crashes.


Where is my mistake?


107
Applications / Re: DOS VDM and Win-OS2 Fans ?
« on: March 18, 2020, 12:25:52 am »
Quote
Having worked on eCS, the fact seamless WIN/OS2 sessions do not work has been the case since eCS. The cause is VSVGA.SYS. It does not matter if you install SNAP, Panorama or GRADD they all use the same VSVGA.SYS driver. Its pretty complex driver VSVGA.SYS that relies on the VESA BIOS/VGA hardware. It just seems not all support in around that VSVGA.SYS is looking for.

But it did work on my former computer with a ATI X300 graphics card (SNAP). So the problems relates to modern graphics hardware ?

108
Applications / Re: DOS VDM and Win-OS2 Fans ?
« on: March 15, 2020, 10:02:39 am »
I use CorelDraw 3.0, 4.0 and 5.0 - these are the Win16 versions - on WinOS2. These versions are much more handy than the overloaded and (still) buggy current versions. I create charts. Most data I use for the charts are on a JFS partition, so I prefer doing this job on my main ArcaOS installation. I know that there's a 2.5 version on OS/2, but this version is not useable because on 3.0 the real important functionality has been added. In 2.5, I can only edit the drawing in outline mode.

For big drawings (I am a traffic planer for railways and, less, roads) I have to use Windows, and even on Windows, I even bring Windows to its knees. Smaller drawings are also possible and useful to draw with Win16.

Then there's an excellent Win16 program where I can manipulate/edit fonts, especially OS/2 system fonts, but I forgot the name and cannot find it on my harddisk anymore. (Hope someone knows the name here.)

I know that I won't ever edit such big plans on OS/2. If I draw these plans, it is a closed separate job from my default work, so it is not a big problem for me. But the performance of Lucide/qpfview on big PDF plans is nervy (in most cases, they have a very big bitmap on the bottom layer). Sometimes I have to start Windows to simply view such plans in a reasonable time. If I can open these big plans with Acrobat4 on OS/2, the performance is OK, but most PDF files need newer versions. I can view my own very big plans with Acrobat4 on OS/2 without problems, even 200 x 60 cm with two bitmap layers which is the biggest format I use.

But since ArcaOS, seamless Windows does not work. A DOS window works if I start a DOS fullscreen and press Alt-Pos1. But Windows Seamless does not work at all. This is a big problem for me, because (1) I have to press Ctrl-ESC to get the necessary data for my charts (2) the performance of Win16-fullscreen driver on Panorama is catastrophic. Dotted lines are drawn with a speed of 3 cm per second (!). It can happen that I have to end the session, because I cannot wait anymore. CorelDraw marks selected objects with a dotted rectangle... So sometimes I in fact cannot move objects which is a basic functionality. But sometimes it works. So I copy my whole project folder to FAT32 and continue working on Windows only for generating my charts.

The new KAM1 bugfix has no effect on my system. I use Panorama on an AM4 board with a Ryzen APU which works fine besides this point. This bugfix would be extremely helpful for me.

109
Programming / Re: Observing if a program uses vio calls
« on: March 09, 2020, 09:23:36 am »
When the "|" command is used to send data to another stdin/out program, I see no problems with my program. Only more and less and its derivates  (which names are also common?) can make problems. But these programs are helpers in a small text window where the output runs into Nirvana. This is the main functionality of my frontend to scroll back without limit. So these helpers are obsolete. I only have to find a useful way how to handle it. Like described above, I could support "| more" in the editor to enable the page-keypress functionality in my editor. In the ME editor when typing
[C:\] dir /s | me in
the default behaviour is not to scroll while output gets received, and this behaviour should be an option in my commandline frontend. My program has already a LED which glows red while the command is compiled and green when a prompt is shown. With ESC, you can easy jump to the prompt.

Our discussion here is very helpful for me. It helps me sorting my own ideas and it prevents me from programming something which does not fit the real purpose of my program.

I will publish a first version in 1-2 weeks. I have decided to name it MeShell.

110
Programming / Re: Observing if a program uses vio calls
« on: March 08, 2020, 09:35:26 pm »
At the moment, my program is already very useful. But I do not want that a user always has to think of if my program fits his purpose or not. So I have to add basic VIO switch functionality. The user often does not know which commands are VIO relevant and which not, even I have to try some programs to see what happens. So the behaviour of my editor should be usable, it does not need to be perfect. It is clear for me that we discuss perhaps 3% of the normal commandline usage, because the majority of commands is stdout-based only and the problems we discuss here do not appear.

Another simple solution of the MORE problem is to create a warning message in the editor. Because the more command depends on the size (line count) of the VIO window, MORE is not a good solution. I have got already a silder where you can reduce the output speed. The leftmost value could generate a pause after one visible page has been written with stdout output. This solution would be completely in the editor. Another option is that this behaviour can be set for one single command by using MORE. So my editor interpretates the MORE command and the rest of the command gets transformed to the command without MORE which is sent to cmd.exe.

An important question for me is if MORE is the only program which requires single keystrokes without creating VIO output before. Does anyone know a second program? If noone knows a second program, this internal editor solution would be perfect.

Anyway, when I publish the first version, everyone can report specific problems.


111
Programming / Re: Observing if a program uses vio calls
« on: March 08, 2020, 03:47:53 pm »
Quote
The problem with sending a WM_CHAR, or indeed any sort of message is that the cmd process doesn't have a message queue. The frame window does, but that's handling messages for the frame window, the system menu etc.

Can I perhaps send a message to the helper (the way I have already programmed via Semaphores and Shared Memory) that a user has pressed a key on the keyboard and the helper program writes the character to the keyboard buffer of its own session?

Thinking about my problem has resolved that if no VIO output happened and the user presses SPACE (SPACE is no useful answer for a menu or Y/N query), it is most likely, that the SPACE has to be sent to the VIO window and not to STDIN. This should cover the majority of cases.

112
Programming / Re: Observing if a program uses vio calls
« on: March 07, 2020, 10:47:33 pm »
Laurence, it 's all right what you have written, but it does not target my problem. Indeed, the user (not my program) sees that keyboard input is expected. But if the user presses a key on the keyboard, my program does not know how to handle it: sending it to the VIO window via WM_CHAR messages (hope this works) or sending it to cmd.exe via STDIN. In the STDIN variant, a whole line is collected in the editor and is sent in a whole line after the user has pressed ENTER. This problem is independent from the MORE and the empty VIO window problem. I have solved recognizing VIO output, but not recognizing VIO input yet. In most cases, the problem does not occur at the surface, because before expecting VIO input, a VIO output has been recognized and the VIO window has popped on top so it catches the keyboard input anyway. It is only the very specific problem if no VIO output has been generated from a VIO program and a user input via VIO is expected. Perhaps we can simply classify MORE as a bug.

With the speical MORE case, it would be perhaps the best option that the editor itself interpretates the "| more" input and stops with output after one page has been written. Or we write a MORE substitute which is identical to the original one, but does not wait for a VIO keypress and instead, it waits for a stdin line (so the user has to press ENTER instead of any key:

---more---- press Enter to continue

The case of
Code: [Select]
more <filename.txthas the same problem/behaviour.

Can we get the original MORE.EXE source code? (I assume it is quite short.) The usage of MORE is quite variable, so an own executable is perhaps more useful than implementing in the editor (which again forces problems when using in cmd files).

113
Programming / Re: Observing if a program uses vio calls
« on: March 07, 2020, 11:35:49 am »
EPM does not support VIO. Even the stdin/out support is very poor. When starting a VIO program in EPM, an error message occurs (TED.EXE) or nothing happens (DFSOS2.EXE).

114
Programming / Re: Observing if a program uses vio calls
« on: March 07, 2020, 09:31:28 am »
I thaught that I have all VIO specific stuff solved (works really nice and handy, with two different positions of the VIO window dependent on the prompt state of the editor window, so nothing important is covered), but there's another special situation which is not programmed yet and where my program still fails:

[C:\] dir | more

more let rest the output at stdout and writes into stdout (not VIO!) an additional line

----more----

and then it waits for a keypress via VIO. Stdin Input always requires pressing ENTER at the end of the line, and VIO accepts a single keystroke.

Now the behaviour of my program is like I have it programmed:

- The "dir" output is shown in the editor and ends with a "----more----" line
- the VIO window does not pop up because there's no output to show (it is still empty or unchanged)
- but the invisible and empty VIO window now expects a keystroke!

In the editor I distinguish between "prompt state" and "not prompt state" (the user types a new command or the last command is still executed). So I can simply send the user input in not prompt state (program is running) to the VIO window by a WM_CHAR message to the Vio Window handle, I think this should work (have not tried yet). But now I get a new problem: I need to know whether a program waits for stdin input (a character or a line which is finished by typing ENTER) or the VIO window waits for a single keystroke. I have no clear solution for this problem yet. Any hints are appreciated. Again, the helper program running in the VIO window could perhaps help me in observing something.

I would not have the problem if MORE would send the "----more----" line to VIO instead of stdout. The MORE substitute on Hobbes (a VIO read only editor where you have to press "q" to quit) runs completely in VIO and makes no problems. Of course users of my program do not need MORE anymore, but it could appear in cmd files. And  there's the question if there are other programs which require VIO console input without writing to VIO or MORE is the only case - all stdout programs with a "press ANY key" (not only ENTER) are candidates for this problem.

Of course, I could scan the last stdout line content by searching "more" or "any key" (oops, how much languages do exist?), but I hope we find a general solution like we did for VIO output by observing the whole screen text buffer.

Perhaps one of these calls can help:
http://www.edm2.com/index.php/Category:Kbd
http://www.edm2.com/index.php/Category:Vio


115
Programming / Re: Observing if a program uses vio calls
« on: March 05, 2020, 09:10:02 am »
If I understand the linked EDM2 FAPI page right, VIO is the only part of OS/2 which is still used in 16 bit and 32 bit VIO has started (I assume about the year 2000, at the end of IBM OS/2 development), while all other FAPI stuff has been rewritten in 32 bit and the conversion project has not finished. In the EDM2 documentation, some but not all VIO calls are documentated in two variants, one 16 bit with (FAPI) and one 32 bit without.

http://www.edm2.com/index.php/VioReadCharStr_%28FAPI%29
http://www.edm2.com/index.php/VioReadCharStr

Some parameters are USHORT in the FAPI variant and ULONG in the non-FAPI (32 bit) variant.

So that means the last correction in EDM2 was false. All VIO calls in the EDM2 documentation which have a FAPI correspondent page have to get a link with a sentence: "VIO 32 (bla bla) needs DLL (bla bla) not supported by default, Link to FAPI call"

Some calls have got a correspondent FAPI entry, others not.

Where are the binaries (DLLs) of vio16 and vio32 and do we have the source code to complete the vio32 calls in a long run? (I don't need this stuff for my editor, meanwhile all works fine.)

116
Programming / Re: Observing if a program uses vio calls
« on: March 03, 2020, 03:20:46 pm »
OK, Laurence. VioReadCharStr works now. TED.EXE which starts at cursorposition (0,0) and ends after writing the screen on cursorposition (0,0) is recognized now. In most cases, only 2000 bytes have to be compared. But anyway, I wonder why I cannot access directly to the buffer address buf_addr of VioGetMode.

Again, the VioReadCharStr length parameter is USHORT, not ULONG. I think the whole VIO EDM2 documentation has to be checked.

Thank you Laurence and Wim again for your valuable hints and explanations !

117
Programming / Re: Observing if a program uses vio calls
« on: March 03, 2020, 08:57:41 am »
First, VioGetBuf has in the edm2 wiki the same wrong description. Length is USHORT and not ULONG. It seems that the 8192 char limitation depends on the USHORT values which are spread all over the VIO calls. If I have true color foreground, background, attributes and the ASCII value, then I need 8 bytes for one cell. I think this is the reason for the 8192 chars limit. That means, even if we write the VIO dll new, all existing programs have got the USHORT values in their code. (Perhaps in Windows, this restriction has not existed since Windows NT?) For a perfect solution, we would need a new VIO32 API interface and a compatibility mode. This is a big thing, so I think that the way I have chosen to pop the original VIO window is the right one for the moment.

------------------

But VioGetBuf does not fit my purpose. I want to copy the screen buffer to compare with an ancient state. VioGetMode fits my purpose. I get a structure VIOMODEINFO which holds lots of interesting information. I have logged some values:

VioGetMode returns rc = 0; buffer length 4000 full length 4000 columns 80 rows 25 address 753664

The length of the buffer is 80 x 25 x 2 = 4000. One byte is for the ASCII value, one for the attribute and colors.

But the address of the screen buffer is too low for a normal memory pointer. memcpy let the program crash, the access to this address is not valid.

The definition in VIOMODEINFO is:

ULONG   buf_addr
ULONG buf_length
ULONG full_length


(Interesting: buf length has got here a 32 bit value and this is really true.)

Any idea how to get access to the data? Perhaps I have to convert this value to a real pointer value.

118
Programming / Re: Observing if a program uses vio calls
« on: March 02, 2020, 06:34:20 pm »
I think I will compare the whole screen buffer (max 2x8192 bytes). If I understand it right, a "cell" is a byte for the ASCII value and a byte for the colors and attributes. VioGetBuf let me show both the length of the buffer and the address. The user can choose whether to compare the Cursor position or the whole screen buffer.

Does anyone know if the screen buffer changes with the "mode" command? Can VIO programs change the window size on their own?

119
Programming / Re: Observing if a program uses vio calls
« on: March 01, 2020, 12:24:54 pm »
In the Borland C header, both parameters row and column are PUSHORT. So we have three different meanings. Anyway, the original 2 times PUSHORT definition works. I assume the are problems if values higher than 65536.

Meanwhile, the new mechanism for popping up VIO windows works! But I have found a program TED.EXE (very old minimalistic editor for editing config.sys on 3,5 inches discs) which is not recognized: It is a pure VIO program and when starting, it draws a menu on the bottom of the VIO window and then it awaits input on the topleft cursorposition (0,0). So my program thinks that there was no input. Are there other useful VioGet... calls where I can additionally query and compare other values than the cursor position? Perhaps comparing the whole screen buffer? (Which is not as big today as it was 20 years before...) I could write user settings for these additional queries.

120
Programming / Re: Observing if a program uses vio calls
« on: March 01, 2020, 09:19:20 am »
I began to program now and I have found a suspect difference between headers of VioGetCurPos:

in
http://www.edm2.com/index.php/VioGetCurPos
the second parameter Row is PULONG, but in my header file (Borland C 2.0), the header file is defined as PUSHORT16. What is correct now? Can someone take a look at a current development environment (Open Watcom?) in bsesub.h ? Thank you.

Pages: 1 ... 6 7 [8] 9 10 ... 17