This message is a reply to Arkady, who had a big look at OpenGEM for me. I'm getting ready for OpenGEM Release 4 at the moment, and preparing OpenGEM Release 4RC1.

As most of you know, OpenGEM is intended to provide a complete 16bit singletasking GUI for the FreeDOS community. You can find out more about it at

1. if pack (inside distributive) with zero
 compression, then its size become 9235k (instead 4550k), but resulting
  distributive become 4395k (insted 4533k - gain -3%). But after packing
  all tree into .RAR, result become 3279k (gain -28%).

Okay, so perhaps I should move to RAR compression? It's something I would like other opinions on. Do most people have RAR compression tools, or would such a transfer potentially confuse users?

2." distributive contains a lot of directories (9) and some
  files, and all of them unpacked into root directory. All of them should
 be installed _inside_ _one_, sensible directory (like GEM3) or, better,
  into asked directory. Simplest way, how to do this (insde install.bat)
  without external dialog utilities:

       @echo off
       if "%1"=="" goto ask-if-install

       rem %1 is a user specified path
       rem check if it exists and try to create it if not
       if not exist %1 md %1
       if not exist %1 echo Error creating target path...
       if not exist %1 goto end

       goto end

       echo ...
       choice /c:1234
       if errorlevel ...
       if errorlevel 2 %0 d:\gem3
       if errorlevel 1 %0 c:\gem3
       ...^C pressed...

  Some batches, which depends on path of GEM, may be created on the fly by

There is a problem with GEM, in that often paths are hard-coded into applications.

3. install.bat: allowed to install only C: and D:.

In fact, in the new OpenGEM Release 4 people will only be able to install to C: I was getting messages of errors when people tried to install to another drive. There is no way that I can fix that myself at the moment, as it appears to be inside the GEM code itself (GEM.EXE perhaps?).

4. install.bat: before asking about installed Windows, should be _also_
  checked %win% variable. But in any case install.bat assumes, that Start
  menu resides in the C:\Windows\Startm~1\Programs, and this is far from
  reliable suggestion.

This is another feature I am removing from OpenGEM. In Release 4, my focus is entirely on FreeDOS, and Windows support is being dropped. This is especially true because WindowsXP et al are causing all sorts of problems using OpenGEM. The shell is just not really compatible with real mode dos I guess.

5. all batch files currently contains absolute path (like setup.bat):

       choice /c:12345
       if errorlevel 5 goto 5
       if errorlevel 1 goto 1

       ECHO OFF
       REM Change the video driver

  First, I don't understand why to use multiple "echo off", also as
  unreachabled "goto" and "cls" after _jump_ to video.bat. Ie., you may
remove those lines. Second, you not process ^C after CHOICE (which return
  zero errorlevel). Third, jumps should be relative (this allows to
  install GEM into any subdirectory):

       CD ..\CHOICE
       choice /c:12345
       if errorlevel 1 goto 1
       ...process ^C...
       REM Change the video driver
       CD ..\SETUP

The multiple ECHO OFF is because on some versions of DOS I noticed something weird. It appeared to start ECHOing inside large batch files even though ECHO OFF had been stated at the beginning of the file.

I'm not sure what you mean by "you not process ^C after CHOICE." Erm...Please expand on that for me. I'm not a great programmer at all (even batch files are largely a mystery to me).

Relative jumps will not be necessary because OpenGEM Release 4 can only go into one place.

  And even shorter:

       apps\sys\choice\choice.exe /c:12345
       if errorlevel 5 goto exit
       if errorlevel 4 goto help
       if errorlevel 3 apps\sys\setup\printer.bat
       if errorlevel 2 apps\sys\setup\sound.bat
       if errorlevel 1 apps\sys\setup\video.bat
       goto exit

Now, this is interesting. I didn't know that we could do this (I told you I was a bad programmer). I guess that the OpenGEM batch files can be made a lot smaller and easier to read by using this. Will this work on all versions of DOS past 3.3?

6. whcarts\: there is .bak file; some timestamps (agenda.wch, chill.wch) are

I will remove the BAK file in any future release of OpenGEM, and fix these timestamps.

7. gemapps\gemsys\chooice\doc\copying duplicates
gemapps\helpzone\license.txt, and choice.exe itself is hidden too deeply.

CHOICE is moved into GEMAPPS\GEMSYS for the new releases of OpenGEM.

LICENSE.TXT is going to stay in HELPZONE, as all documents associated with OpenGEM are stored here. However, LICENSE.TXT is also included on the first level of the downloadable ZIP file, so it's one of the first things people see, along with README.TXT.

This is may impressions about setup and run process. If you wish, I continue
my remarks about working insid GEM. Also, if you wish, I may rework batch
files for you.

I will be releasing OpenGEM Release 4RC1 on the 20th of June. It would be wonderful if you could have a look at this substantially different version of OpenGEM (which will included some of the changes you have suggested), and let me know what you think! I will post to the FreeDOS list when the new version of OpenGEM is online.

Thank you so much


SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast.
Freedos-user mailing list

Reply via email to