DOS ain't dead

Download: http://sourceforge.net/projects/doszip/files/

All inline execute of programs is now removed. This was used to spawn programs on top of Doszip to compile from the editor or create list file for plugins. However, this will only work if the program is a NT executable using minimal conventional memory, so these features only apply to the NT-Dosbox.

There is now also a Win32 version of Doszip available.


Changes in 2.50 - 28 Sep 2013
- fixed bug(s) in Filter dialog -- Date, Size

Changes in 2.49 - 19 Sep 2013
- fixed bug on Enter in Editor -- fails if cursor inside Tab-field
- fixed bug on Create Directory in .ZIP files
- added auto detect CR/LF to Edit
- added DOC directory (switch /C<path>) for help and configuration files
  -- .\doszip.txt  - Doszip help file (F1)
  -- .\license.txt - GNU GENERAL PUBLIC LICENSE (About-F1)
  -- .\dz.ini      - main configuration file
  -- .\config      - binary runtime configuration
  -- .\history     - text file containing commands, open files, ...
  -- .\style       - directory for Syntax Highlighting files (Edit)
  -- .\edi         - directory for editor project files (.edi)
  -- .\pal         - directory for color setup files (.pal)
- removed NT (DOSBox) execute Editor commands
- removed NT (DOSBox) execute 7ZA (Plugins) commands

Changes in 2.48 - 16 Jul 2013
- fixed bug in Edit Reload -- first memory block still not cleared


> There is now also a Win32 version of Doszip available.

A new era for DosZip has begun!

However, I tried the Win32 version - and my impression is that it cannot fully compete with FAR commander yet. Actually, its user interface feels a bit unstable. Changing the directory "doesn't work", for example.

---
MS-DOS forever!

> > There is now also a Win32 version of Doszip available.
>
> A new era for DosZip has begun!

work in progress

> However, I tried the Win32 version - and my impression is that it cannot
> fully compete with FAR commander yet.

I tried to execute BCC.EXE and BC.EXE in FAR ...

> Actually, its user interface feels a
> bit unstable. Changing the directory "doesn't work", for example.

Hit Alt-1

[Comspec]
00=%SYSTEMROOT%\SYSTEM32\CMD.EXE
01=/S /C

change to:

[Comspec]
;00=%SYSTEMROOT%\SYSTEM32\CMD.EXE
;01=/S /C


>
> > However, I tried the Win32 version - and my impression is that it cannot
> > fully compete with FAR commander yet.
>
> I tried to execute BCC.EXE and BC.EXE in FAR ...
>
I assumed I managed to fix that but it seems I was fooled by a .pif-file...

Running BCC from the command line returns with a command prompt.

It is the same problem I had with the 16-bit version in reverse
with the communication between CMD.EXE and COMMAND.COM.

A .pif-file on the desktop will fix the issue, a .lnk-file creates problems.

> I tried to execute BCC.EXE and BC.EXE in FAR ...

You should probably rather test DZ.exe, not FM.exe!

> Hit Alt-1
>
> [Comspec]
> 00=%SYSTEMROOT%\SYSTEM32\CMD.EXE
> 01=/S /C
>
> change to:
>
> [Comspec]
> ;00=%SYSTEMROOT%\SYSTEM32\CMD.EXE
> ;01=/S /C
>

Tried, but doesn't make any difference. Btw, when I launch DZ.exe from inside FM and then press Alt-1, DZ.exe immediately terminates - looks like it doesn't expect the console screen size set by FM!?

---
MS-DOS forever!

> You should probably rather test DZ.exe, not FM.exe!



True, but I was curious to see how it handle the issue
I struggle with this problem using JWASM in the editor
but this was 16-bit executing 32-bit, now it's reversed

> > change to:
> >
> > [Comspec]
> > ;00=%SYSTEMROOT%\SYSTEM32\CMD.EXE
> > ;01=/S /C
> >
>
> Tried, but doesn't make any difference.
>

I assumed command.com was the default %comspec%, maybe not ?
[Comspec]
00=%SYSTEMROOT%\SYSTEM32\COMMAND.COM
01=/C

but using COMMAND will prohibit use of NT associated files like .CMD and .TXT
The System Options (Ctrl-F8) controls this in the "[x] Use NT Prompt"
This will execute everything on the command line assuming CMD == %comspec%

the current directory in NT is not the same as in a DOSBox (NTVDM)
however, this should work in both cases so this is a bug..

the 16-bit version is always in DOS-mode, using interrupts to handle this
so that simplifies the issue a bit, but the combination is a problem

> Btw, when I launch DZ.exe from inside FM and then press Alt-1,
> DZ.exe immediately terminates
> - looks like it doesn't expect the console screen size set by FM!?

I tried this and there was no problem:

FM started with 50 lines (full screen)
Executed DZ (enter) started with 25 lines, Alt-1 worked
Exit DZ, FM now using 25 lines

The System Options controls this in the "Startup: [x] Restore Screen Mode"

removing the 'x':

FM started with 50 lines, DZ started with 50 lines, Alt-1 worked
Exit DZ, FM now using 50 lines

Starting FM in a window start with 25 lines, DZ 25, Alt-1 worked, ...

A major fault of logic there...

The 16-bit version exits on executing the CD command
The loading process then adapt the current panel to the current directory

Now it just issue the command and continue

Good catch, thanks!

> > - looks like it doesn't expect the console screen size set by FM!?
>
> I tried this and there was no problem:
>
> FM started with 50 lines (full screen)

Yes, fullscreen works. However, I run FM in windowed mode. First I enter Alt-F9 to make the FM window use the full screen ( it has more than 80 columns then ), second I launch dz.exe, and third I press Alt-1 - dz.exe terminates.

---
MS-DOS forever!

> > > - looks like it doesn't expect the console screen size set by FM!?
> >
> > I tried this and there was no problem:
> >
> > FM started with 50 lines (full screen)
>
> Yes, fullscreen works. However, I run FM in windowed mode. First I enter
> Alt-F9 to make the FM window use the full screen ( it has more than 80
> columns then ), second I launch dz.exe, and third I press Alt-1 - dz.exe
> terminates.



I've never seen that before. That was very nice, it filled the whole screen.

DZ set 25 lines in this case, but if the "Startup: [x] Restore Screen Mode"
is removed, and it try to adapt to this screen, it also terminates.

The editor always tries to fill the whole screen, so this will fail to.
The viewer also fails for the same reason, so there are some issues.

My knowledge of the graphical GUI window is very limited. I'm still in "text-mode", so I need some time to figure out how this works. From the limited testing I have done it appear to be different rules for the GUI window compare to text-mode. Different mouse driver, where you can use the mouse-wheel in graphical mode, but not in text-mode, and the size issue also differ.

Well, I manage to fix the CD and X: commands, and the graphical full screen looks good, so I will see if I at least could adapt to it by extending the screen buffers horizontal as well as vertical.

> My knowledge of the graphical GUI window is very limited. I'm still in
> "text-mode", so I need some time to figure out how this works. From the
> limited testing I have done it appear to be different rules for the GUI
> window compare to text-mode.

To find out the current screen dimensions, you have to call GetConsoleScreenBufferInfo(). Actually, this should be done in both full-screen text mode and windowed GUI mode.

---
MS-DOS forever!

>
> To find out the current screen dimensions, you have to call
> GetConsoleScreenBufferInfo(). Actually, this should be done in both
> full-screen text mode and windowed GUI mode.

Yes, that is what I'm currently using to get the metrics of the screen:

consinit proc
local ci:CONSOLE_SCREEN_BUFFER_INFO
        invoke  GetConsoleScreenBufferInfo,hStdOutput,addr ci
        test    eax,eax
        jz      toend
        mov     eax,ci.dwSize
        movzx   ecx,ax
        mov     _scrcol,ecx
        shr     eax,16
        dec     eax
        mov     _scrrow,eax
        invoke  cursorget,addr console_cu
        invoke  free,console_dl.dl_wp
        mov     eax,_scrrow     ; save init screen
        mov     ah,byte ptr _scrcol
        inc     al
        invoke  rcpush,eax
        mov     console_dl.dl_wp,eax
        mov     console_dl.dl_flag,_D_DOPEN
        mov     eax,_scrrow
        inc     eax
        mov     console_dl.dl_rect.rc_row,al
        mov     eax,_scrcol
        mov     console_dl.dl_rect.rc_col,al
  toend:
        ret
consinit endp


However, setting the screen metrics is a different matter (I think), and it seems to involve some graphical functions of getting/setting the client window using pixels as measure. I assume you then have to calculate the size of the desktop by measure the font size currently used.

The current approach for doing this is rather simplistic:

.data
mode db 'MODE CON LINES=%d',0

.code

conssetl proc l:dword   ; line: 0..max
local cmd[64]:byte
local ci:CONSOLE_SCREEN_BUFFER_INFO
        mov edx,l
        .if edx != _scrrow
            inc edx
            invoke sprintf,addr cmd,addr mode,edx
            invoke command,addr cmd
            .if GetConsoleScreenBufferInfo(hStdOutput,addr ci)
                mov eax,ci.dwSize
                shr eax,16
                dec eax
                mov _scrrow,eax
            .endif
        .endif
        ret
conssetl endp


This only assume vertical changes where the width is static (80), so I need to add the a line with COLS=%d to get back to the "good old" 80x25 mode.

I extended the buffering for the functions that handle text in/out-put from 80 to 256. But this is the limit on "graphics" used since the definition of a RECT is BYTE sized. By doing so the program is able to adapt to larger screen metrics, but the panels and text viewer is still (v3.03) using 80. However, the editor is able to adapt to a larger line width.

Now I have changed the width of the panels and text viewer as well, so the program is now capable of adapting but still not able to set and move the client window. The current solution to this is to do this manually by having a short-cut (.LNK) to DZ on the desktop. You may then set the metric there to fill the whole desktop, and remove the "Startup: [x] Restore Screen Mode" in the system option dialog. DZ will then adapt to this metrics, and also adapt to the metrics if executed from FM, but flipping from a window to text mode (Alt-Enter) will be a problem.

A single (large) panel:

>
> ... and it
> seems to involve some graphical functions of getting/setting the client
> window using pixels as measure. I assume you then have to calculate the
> size of the desktop by measure the font size currently used.

The few full-screen console Win32 applications that I wrote don't care about pixels or fonts - and they work fine when launched by "full-sized" FM. All they use is the CONSOLE_SCREEN_BUFFER_INFO.dwMaximumWindowSize member.

---
MS-DOS forever!

>
> The few full-screen console Win32 applications that I wrote don't care
> about pixels or fonts - and they work fine when launched by "full-sized"
> FM.

Well, FM is setting the "full-sized" window then

> All they use is the CONSOLE_SCREEN_BUFFER_INFO.dwMaximumWindowSize
> member.

That is the same as .dwSize:
main      proc c
local   ci:CONSOLE_SCREEN_BUFFER_INFO
        .if GetConsoleScreenBufferInfo(hStdOutput,addr ci)
            mov eax,ci.dwSize
            movzx ecx,ax
            shr eax,16
            dec eax
            invoke printf,"COLS:\t%d\nROWS:\t%d\n",ecx,eax
            mov eax,ci.dwMaximumWindowSize
            movzx ecx,ax
            shr eax,16
            dec eax
            invoke printf,"MaximumWindowSize:\n COLS:\t%d\n ROWS:\t%d\n",ecx,eax
            invoke getch
        .endif
        sub eax,eax
        ret
main    endp

Executed from Windows:
COLS:   80
ROWS:   24
MaximumWindowSize:
 COLS:  80
 ROWS:  24


Executed from Doszip in a large-size window:
COLS:   140
ROWS:   48
MaximumWindowSize:
 COLS:  140
 ROWS:  48


The GetLargestConsoleWindowSize function returns the size of the largest possible console window,
based on the current font and the size of the display.
COORD GetLargestConsoleWindowSize(
  HANDLE hConsoleOutput   // handle to console screen buffer
);

The SetConsoleWindowInfo function sets the current size and position of a console screen buffer's window.
BOOL SetConsoleWindowInfo(
  HANDLE hConsoleOutput,  // handle to console screen buffer
  BOOL bAbsolute,         // coordinate type flag
  CONST SMALL_RECT *lpConsoleWindow
                          // address of new window rectangle
);

I will do some testing...

The metric changes by using these functions
However, the window do not change or move

GetLargestConsoleWindowSize:
- in text mode 80x25 the maximum size returned is 80x49
- in a 80x25 window the maximum size returned is 96x34

SetConsoleWindowInfo:
- this functions do as it says: it sets the window info
- but the only visible change is added scroll-bars in a window

Solution:
- do "MODE CON COLS=%d LINES=%d" with values from GetLargestConsoleWindowSize
- this works in both text-mode and in a window

problem solved

The Alt-F9 key should work now..

Changes in 3.04 - 2 Oct 2013
- added support for full screen size (Alt-F9)
- added Mouse-Wheel functions to Edit and View
- fixed a few bugs in the Editor -- Syntax Highlighting

> The Alt-F9 key should work now..

Yes. Very cool!

There's still a problem with the navigation. I've "installed" dz.exe in directory C:\TEMP\DZ32. After dz.exe has been launched, I cannot leave this directory - navigating to the ".." and then pressing ENTER is ignored. If I change the drive to D: or any other drive, navigation is no problem.

Another issue is the keyboard interface. If I try to enter a backslash, the key is ignored. On a German keyboard, to enter a backslash you have to press and hold Alt-Gr ( which is the RIGHT alt key ), then enter another key.

---
MS-DOS forever!

> There's still a problem with the navigation. I've "installed" dz.exe in
> directory C:\TEMP\DZ32. After dz.exe has been launched, I cannot leave this
> directory - navigating to the ".." and then pressing ENTER is ignored. If I
> change the drive to D: or any other drive, navigation is no problem.
>
Same thing happens here -- drive C is FAT32, and the rest is NTFS
Also, the "CD .." do not always work -- you may have to repeat the command
chdir():
        .if SetCurrentDirectory(directory)
            .if GetCurrentDirectory(WMAXPATH+1,addr abspath)
                mov al,abspath
                .if al <= 'z' && al >= 'a'
                    sub al,'a' - 'A'
                .endif
                mov env_var[0],'='
                mov env_var[1],al
                mov env_var[2],':'
                mov env_var[3],0
                .if SetEnvironmentVariable(addr env_var,addr abspath)

todo..

> Another issue is the keyboard interface. If I try to enter a backslash, the
> key is ignored. On a German keyboard, to enter a backslash you have to
> press and hold Alt-Gr ( which is the RIGHT alt key ), then enter another
> key.

Yes, the Alt-Gray key is a problem
The scan-keys that are hooked up are:
03 04 05...08 09 0A 0B...1B 0D
...
0340 at
04A3 sterling
0524 dollar
087B braceleft
095B bracketleft
0A5D bracketright
0B7D braceright
1B7E asciitilde
0DB4 acute

This also needs to be fixed somehow..

CD and Alt-Gray key seems to works now..

Changes in 3.05 - 3 Oct 2013
- fixed bug in Keyboard -- Shift keys and Mouse state "hang" after execute
- fixed bug in Keyboard -- Alt-Gray key (char)
- fixed bug in Change Directory -- Enter, "CD..", and "CD "

> CD and Alt-Gray key seems to works now..

Confirmed! Impressive! Virtually like FM, with a binary size of just 150 kB!

I also tried in DOS with HXRT, works also pretty good ( the editor seems to be in "mark" mode when started; most likely a bug in the HX Win32 emulation ).

Suggestion: enable "Long Filenames" mode on startup for the Win32 variant.

---
MS-DOS forever!

>
> I also tried in DOS with HXRT, works also pretty good ( the editor seems to
> be in "mark" mode when started; most likely a bug in the HX Win32 emulation
> ).

No, that is me trying to emulate the [0040:0017] address (int 16:12) by having the shift-state accessible as a static value. There is no way (as far as I know) to determine the current shift state in Windows, so this has to be stacked from reading the event handler.

On executing a program from a Ctrl/Alt/Shift-<key> the shift-state is on, and the reset of the flag comes from a ?KeyReleased? event, which in this case is read by the child tread. On returning, the shift-key is still on, so this creates a problem for the mouse and shift key state.

This is possible to handle on executing a program by simply clear the flag before execution, but this is multi-treading, so you need to know if the window is active, or lurking in the background. When this happens, the flag has to be cleared as well. Maybe there is a simple way to test this (there obviously should be) so the keyboard could be flushed in that case.

>
> Suggestion: enable "Long Filenames" mode on startup for the Win32 variant.

I think this is the default now, and ?short names? may not be available, so ?short? is now only a graphical thing for smaller panels. Time is added to the short-detailed view, and 8.3 sized cols are used in short-list-view. The short name is used if available, else the long name is used.

The combination of F12 (single panel view) and short-list-view enables a lot of visible files on screen, but with a small font in graphical view the printing of text to the screen becomes very slow. This will now be written to memory first and then dumped to the screen for faster screen updates.

There is currently also a wrong calculation of cell-cols in the panels, so the dynamic panel-size is not very good. In 80x25 mode, using short-list-view, which is three columns, only two are used for printing.

There was a few combinations of keys that created some problems, so the short-key handling was (and may still be) not perfect, but it seems to improve. The screen output is also better now, especially for the panels and the editor. Selecting files and hit F4, or drag files to the Edit command on the Statusline is also working now.

Changes in 3.06 - 4 Oct 2013
- fixed bug in Command Prompt -- Ctrl+Alt made an eternal loop - hard error
- fixed bug in Keyboard -- added reset of shift-state on exec and inactive window
- fixed bug in Edit -- Search Dialog exited editor
- fixed bug in Edit -- Open selected files didn't work
- added fast screen update for larger panels
- added fast screen update for Editor -- less update of screen

The problem with executing old .EXE?s (BC/BCC/... is now solved by using a .BAT file to execute these .EXE?s. There is however now an issue with redirection like JWASM -? > jwasm.txt, so this may also need some special handling.

The process approach to "hide the screen and execute" was also a problem, so a full "shutdown" of all screen activity was needed. A command like MODE CON LINES=25 should now work, and DZ should then reload with the new screen metrics.

Windowing, like moving a dialog box using the mouse, generate flickering of the screen do to the slow screen functions in a window compare to text mode. The approach to hide the window, update the positions, and then show the window is basically to slow. In 16-bit you have direct access to the screen, so then you just move each WORD directly to avoid this problem, but this is not not so in graphical mode. The way it is done now is to read a copy of the dialog and dump this the the new location without hideing the original. The saved buffer is then updated in memory. The problem is in the editor when you flip between open files using F6. This is now solved by flipping the save-buffer in memory an overwrite.

In the editor the screen was updated for each keystroke, so this generated some flickering as well. This is now solved by setting a CRC value of the screen output, and only update the screen if this changes. This had some side effects with blank screens, but hopefully this is now fixed.

The console window also have a slow-cursor problem, so the keyboard properties may need an update. You may use the REG command for setting these values.

Install.cmd:
REGEDIT4

; @ECHO OFF
; CLS
; REG EXPORT "HKCU\Control Panel\Keyboard" Keyboard.REG
; REG IMPORT "%~f0"
; EXIT

[HKEY_CURRENT_USER\Control Panel\Keyboard]
"KeyboardDelay"="0"
"KeyboardSpeed"="31"

uninstall.cmd:
@ECHO OFF
REG IMPORT Keyboard.REG

It is possible to use JWASM or other tools to compile the file you currently edit. The short keys Shift-F1..F9, and Alt-F1..F6 could be hooked for this pupose. The output can be viewed by hitting Ctrl-O.

If a .ERR file is produced as a result of this, then this will be read into a buffer, and error messages will appear in the editor. This will also collect external file with error codes, like include files, and these files will be loaded into the editor displaying the line of error. You may flip back and forth in the error list by using Alt-F7 and Alt-F8.

With regards to changing colours, the best way to do this is by creating a .LNK file to DZ, and change the properties there. In the 16-bit version you are able to manipulate the palette directly, and thereby setting the background colour of Push-Buttons and Title-Lines to white. This is not possible in now (white: Fh), since a value above 7 activates the blink function. The current colour used is green, but this may now (I think) be changed in this property dialog.

Changes in 3.08 - 9 Oct 2013
- added user screen (Ctrl-B) -- not fully implementet
- rewrote process functions -- update screen metrics
- fixed bug process functions -- execute old .EXE failed (BCC.EXE/...)
- fixed bug(s) in console functions on large screens
- fixed bug in inflate (Unzip) -- stored entries failed
- fixed bug in inflate (Unzip) -- password decryption failed
- fixed bug in inflate (Unzip) -- exploaded entries failed
- fixed bug in Doskey -- index not updated after execute

Changes in 3.07 - 6 Oct 2013
- fixed Zip/Unzip functions -- not fully implemented
-- copy including overwite of existing file(s) failed
-- edit file inside Zip archives failed
-- delete failed in some cases
-- added new streams for fast compression
- fixed bug(s) in screen updates in panels and edit
- fixed bug(s) in Menus and statusline -- visual
- rewrote event handler -- removed Ctrl hook-up

> The problem with executing old .EXE?s (BC/BCC/... is now solved by using a
> .BAT file to execute these .EXE?s. There is however now an issue with
> redirection like JWASM -? > jwasm.txt, so this may also need some
> special handling.

Besides CMD or 4DOS, I don't think most true DOS shells (e.g. FreeCOM) allow you to redirect .BAT output directly, so you have to do "%COMSPEC% /c blah.bat > blah.out".

But I assume you already knew that, so I dunno, just trying to be helpful anyways.

> > The problem with executing old .EXE?s (BC/BCC/... is now solved by using
> a
> > .BAT file to execute these .EXE?s. There is however now an issue with
> > redirection like JWASM -? > jwasm.txt, so this may also need some
> > special handling.
>
> Besides CMD or 4DOS, I don't think most true DOS shells (e.g. FreeCOM)
> allow you to redirect .BAT output directly, so you have to do "%COMSPEC% /c
> blah.bat > blah.out".
>
> But I assume you already knew that, so I dunno, just trying to be helpful
> anyways.

It's only a valid .EXE that is executed directly (like JWASM), so all other commands uses %COMSPEC%.

There are some exceptions to this as mention above, but the redirecting thing is also a problem, and in this case "blah.bat" should be:
@echo off
JWASM > JWASM.TXT

The command executed will then be %COMSPEC% /c blah.bat
Instead of JWASM > JWASM.TXT which will result in:
Fatal error A1106: Cannot open file: "." [6]
Fatal error A1106: Cannot open file: ".." [6]
Error A2106: Cannot open file: "jwasm.txt" [ENOENT]

So you may argue that this is a weakness in JWASM which is unable to handle the '>' argument.

The problem is that some .EXE's creates problems executed directly (depending on what %COMSPEC% actually is), and to fix this a .BAT extension should be used for this (not .CMD). But in addition to this, redirected commands should also have the same handling.

This may be the reason the command above and the .EXE-thing fails in FM.