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] 2 3 ... 16
1
Utilities / Re: MeShell commandline frontend timetable
« on: August 13, 2020, 10:54:14 am »
MeShell 0.81 could crash when browsing the command history with Cursor Up/Down. In the new navigation window, the button names in english language were complete false. MeShell Version 0.82 fixes this and other minor stuff.

2
Utilities / Re: MeShell commandline frontend timetable
« on: August 09, 2020, 09:35:20 am »
MeShell Version 0.81 fixes a handful of bugs (including a crash with command history cursor up / down) and n the settings book the "Save" page it has a setting where you can limit the length of the output history. So far it has grown endlessly. The oldest entries are no longer saved.

3
Utilities / Re: MeShell commandline frontend timetable
« on: July 24, 2020, 09:56:57 am »
MeShell Version 0.80 with navigation tree window is available.

The development of the MeShell commandline frontend is now functionally complete.

In the navigation window there is a "normal mode", in which the current directories are shown in the first level and the entered commands in the second. Then there is an "Error Mode", in which only the lines are displayed where the previous stderr output has taken place. This is useful for long batch files to find the error lines.

The OS/2 project MeShell is now basically finished. On my side, all functionality I have considered are implemented now. However, bugs are certainly still included, although in decreased number. Please send me remaining bug collections with instructions on how to reproduce them.

Not much will happen on the OS / 2 platform until 1.0. I want to finish the Windows version in 0.90, 0.9X will continue bug fixing on both platforms.

I hope that MeShell helps the guys running text mode compilers for porting programs to OS/2.

4
Utilities / Re: MeShell commandline frontend timetable
« on: July 23, 2020, 07:45:28 pm »
I have now completed MeShell version 0.72 . A whole series of inconsistencies have been corrected again.

MeShell changes the input lines. If a PM program is called, "start" is automatically set in front of it. If you accidentally call a Win32 or Win64 program, then my computer did crash. A Win32 / 64 program is now recognized and "pe" or "pec" is set in front of it. A Win64 program is acknowledged with an "echo (error message)".

The completion syntax was sometimes incomplete or incorrect. Commands with included directory names have not yet been completed, you can do that now. Please report constellations where completion still doesn't work properly.

I am considering whether to switch the display of the hint window, where directory structures are searched while typing, to a separate thread. I have a fairly fast computer, there is only a noticeable delay when navigating through a CD drive. You can write if you are annoyed.

5
Applications / Re: Painting program?
« on: July 19, 2020, 11:00:10 pm »
There are three old vector graphics programs: logoart, CorelDraw 2.5 and DrawIt.

6
Programming / Re: Table of similar API calls for OS/2 and Windows ?
« on: July 15, 2020, 11:46:31 am »
Are there download links for the toolkit?
I could take a look at the h files, I hope I will see the direct API call correspondences.

I have got an OS/2 program and want to get a Windows program. (It is the reverse direction.)

7
Programming / Re: Table of similar API calls for OS/2 and Windows ?
« on: July 13, 2020, 11:25:10 am »
I have copied an old win32.hlp / win32.cnt from a Borland C 5.0 CD from 1996. There the pure Win32 API is described. It should fit my purpose better than current descriptions. Winhlp32.exe works fine with Odin.

Open32.inf has no description of the Win32 API calls included. Is the source code of Open32 available? There the translations (both OS/2 and Win32 API calls) should be shown.

8
Programming / Re: Table of similar API calls for OS/2 and Windows ?
« on: July 12, 2020, 09:02:49 am »
The purpose is porting the OS-specific parts of MeShell (pipes, semaphores, VIO buffer access, exceptions) from OS/2 to Windows. It is only a small percentage of the code (ME is already platform-independent), but they are very specific calls.
The Open32 docu only shows the Windows calls, but it is only a subset of the most common calls.

9
Programming / Table of similar API calls for OS/2 and Windows ?
« on: July 11, 2020, 11:13:01 pm »
Does a tutorial or list of corresponding API calls for OS/2 and Windows, like DosCreateNPipe (OS/2) and CreateNamedPipe (Windows) exist somewhere?

10
I have updated MeShell to 0.71. Not tried it yet, but with 4os2 now the command length limit should be 2048 characters.
Here you can download MeShell 0.71 (700 kB)

11
You can write a cmd file. The limit of a single commands in a cmd file seems to be 1023 characters.

The limit when typing a command in cmd.exe is 259 characters. It seems to be syntax specific. A longer input shows an error message:

SYS1065: The input line is too long.

In MeShell, there is a limit of 255 characters because of a bug. It will be fixed in the next version 0.71. Then the combination of MeShell and 4os2 will work with longer lines. Together with cmd.exe, you will have a limit of 259 characters again.

12
Utilities / Re: MeShell commandline frontend timetable
« on: July 09, 2020, 03:28:04 pm »
MeShell 0.70 with syntax completion (command completion and file name parameter completion) is finished.

Here you can download MeShell 0.70 (700 kB)

You will find a new chapter "Syntax completion" in the docu.

The functionality is more extensive than in 4os2 or in Windows. There are also useful hint windows with different colors. You can turn on and off every feature on the "Complete" page of the settings notebook. The settings are also explained in the docu, page Settings Notebook - Complete.

There are also again other bugs fixed.

13
Programming / Re: MeShell problem - start progname inherits stdin/out
« on: July 03, 2020, 11:36:22 pm »
I have chosen now renaming the pipe if the old pipe is still occupied. It was quite complicated, because I already need to count the pipes for several instances of MeShell. I could choose this option because I have the luck that when starting a PM app from cmd.exe, the inpipe is not inherited (because a PM program cannot read keyboard input from an inpipe, but it could create stdout and stderr output). The instances are counted Pipe1, ...Pipe2, Pipe3 for the inpipe and the first free pipe is the instance number which influences colors and default directories. The stdout and stderr pipes ends with A1, A2... If PipeA1 fails for stdout and stderr because it is still occupied from the started PM program, PipeB1 is tried and so on.
It works fine already. So now I have no restrictions at all when starting a PM application and it gets the current directory by default.

14
Programming / Re: MeShell problem - start progname inherits stdin/out
« on: July 01, 2020, 02:46:55 pm »
Yes, it is an option. But it gets more difficult if there are several parameters. I can compare all parameters with the filenames in the current directory and automatically expand the filenames.

Another option would be to start the app directly from the editor and to send a remark to cmd.exe:

rem e textfile.txt (started via MeShell)

Then, renaming the pipe when failing is still an option. I realized now: Because cmd.exe stdin does not fail (only stdout and sterr is inherited), it will be possible to find out whether the pipe is occupied by a started and still running app or by another MeShell instance.

So I have three options to solve the problem.

15
Programming / Re: MeShell problem - start progname inherits stdin/out
« on: July 01, 2020, 12:13:12 pm »
Thank you Laurence!

start /I e indeed works fine.

I have implemented a function where MeShell compiles the string before sending it to cmd.exe. When starting an application, MeShell calls DosQueryAppType and if it is a PM program, it changes the call string to
[C:\] start /I mypmprog

But now, the started PM program does not inherited the current directory of cmd.exe anymore. I haven't found a parameter how to enter the current directory. So a call like

START /I e textfile.txt

fails because textfile.txt resides in the current directory an not in C:\. Any idea?



Pages: [1] 2 3 ... 16