Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd, 

> On Feb 12, 2024, at 5:58 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> I am one step further. I installed dosfstools via zypper and ran the RBE 
> install script again. It showed the following output:
> 
> required lower permissions for creating DOS filessystems.
> '/usr/sbin/mkfs.msdos' -> '/home/rbe/bin/make-dosfs'
> required lower permissions for labeling DOS filessystems.
> '/usr/sbin/fatlabel' -> '/home/rbe/bin/fatlabel'
> 
> So, I finally know where this make-dosfs comes from :-) Perhaps you can add 
> *dosfstools *and *unzip *to the package dependencies in the install script? 
> These are the two I had to install manually after setting up the container.

Hmmm, this is interesting. 

During my test with 15.5 earlier today, I did not need to manually install 
ether of those packages by hand. The install script for the RBE worked without 
issue. Makes me wonder why your install of 15.5 was different. But, it would 
not hurt to include those packages. 

> 
> Sadly QEMU times out. Probably because it is running without KVM. I have not 
> found yet a solution to enable it for the container. This takes longer than I 
> wanted to, so I will dump the container and set up a proper VM…

Hmmm, possibly openSUSE does not install those missing packages by default when 
installing to a container. 

Well, you could possibly just increase the timeout setting for in the 
custom.cfg file. But, if the pieces that use QEMU are so slow it will really 
drag during a couple places when it is doing stuff that can only be done in DOS 
at present. Mostly, that is installing boot loaded and generating the SLICER 
archive for the floppy edition.

Side note… When not in verbose mode, the RBE runs those without any sort of 
display. It spawns them in their own sub shell and monitors waits for that to 
finish. If the elapsed time is exceeded, it assumes it has hung, kills the 
process and the build aborts. The RBE also verifies the result of the QEMU task 
to make sure it completed without an error. 


> BTW your scripts look pretty good, and apart from the trouble caused by 
> myself this all seems to run very smooth…

Thanks.

With all the changes to many things in FreeDOS release itself, this version 3 
(i think) has resulted in a lot of spaghetti in the code. Plus adding things 
like multitasking to work on multiple packages simultaneously at different 
stages contributed to that as well. But, that cut the build time by more than 
50%. So, the increase in performance was definitely worth it.  

Going from nothing and building all the different release media. Pulling the 
different packages and sources down from the internet. Comping on all those 
different packages making metadata and ZIP archives. Modifying the FreeDOS 
installer batch code for all the different languages, keyboads and fonts. And 
that only scratches the surface of all the things that happen when building a 
release. 

It would be cool if someday we developed a standard for the DOS packages that 
would provide a simple method to compile each of the programs from source. 
Then, provide the RBE with an option to do that as well.

The RBE has received many changes over the years. It’s far from perfect and 
could still use a lot of streamlining and other general improvements. Maybe 
that will happen if I ever get around to making the next incarnation of the RBE.

Even as it is now, it is still kind of a marvel to watch in action. 

> 
> Bernd

Keep me posted on your efforts.

:-)

Jerome



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP

[Bernd Böckmann via Freedos-devel]

I am one step further. I installed dosfstools via zypper and ran the RBE 
install script again. It showed the following output:


required lower permissions for creating DOS filessystems.
'/usr/sbin/mkfs.msdos' -> '/home/rbe/bin/make-dosfs'
required lower permissions for labeling DOS filessystems.
'/usr/sbin/fatlabel' -> '/home/rbe/bin/fatlabel'

So, I finally know where this make-dosfs comes from :-) Perhaps you can 
add *dosfstools *and *unzip *to the package dependencies in the install 
script? These are the two I had to install manually after setting up the 
container.


Sadly QEMU times out. Probably because it is running without KVM. I have 
not found yet a solution to enable it for the container. This takes 
longer than I wanted to, so I will dump the container and set up a 
proper VM...


BTW your scripts look pretty good, and apart from the trouble caused by 
myself this all seems to run very smooth...


Bernd

On 12.02.2024 16:03, Jerome Shidel via Freedos-devel wrote:

Hi Bernd,

So…

I booted the (Windows 10) machine that I use for creating FreeDOS 
builds. (Host OS should not be relevant.)


There was an update to VirtualBox. So, I installed that and the 
related new extension pack.


/( Following the instructions in the RBE’s Wiki. Except for CPU’s, I 
went with 2 cores for a reduced build time. )/


I created a new VM for the RBE.

I download a fresh copy of openSUSE 15.5 Leap DVD install for x86. 
/(newest version)/


/( I had a little trouble downloading openSUSE. My home internet was 
recently upgraded to a 1Gb connection. With the standard mirror, I 
would download for a few seconds at very fast rate. Then just stop at 
some point. After switching to a different mirror, it downloaded 
without problem. It makes me wonder if the first server was having 
issues with the much faster rate. Possibly, it considered it a DDOS. 
But, it could just be Windows. After all, I was having issues pulling 
up GitLab on that machine and no issues on the Mac sitting next to it. 
Then again, maybe since the new router fully supports IPv6, IDK. Only 
a couple days since the upgrade and this was the only time I’ve had an 
issue. Time will tell. )/


I installed openSUSE.

/(Note: I need to update wiki. Earlier versions of the openSUSE 
defaulted to activating/*online repositories*/. Now you have to 
choose. They need to be enabled for the install script to fetch 
additional required packages. Otherwise, I used my normal location 
settings and such. Finally (per wiki instructions), I selected the 
system role as server.)/
After the install of openSUSE, I continued to the /Install Builder 
Tools/ page in the wiki.


Used zypper to install git: *git sudo zypper install git*

Cloned RBE project: *git clone https://gitlab.com/FreeDOS/OS/builder.git*

Moved to the Builder directory: *cd builder*

Ran the install script for the RBE: *sudo ./install*

Rebooted. (End of wiki)

Logged in as normal user and changed dir to the *builder* dir.

Ran: *make*

/(waited a while watching build process)/

Result, Successful Build of a “Standard Release”

Ran: *make clean*

Edited custom.cfg to:

*unstable=yes*
*verbose=yes*


Ran: *make*

/(waited a while watching build process)/
/
/
Result, Build failed from unknown issue while creating bootable 
floppy. However, I never use verbose mode in the normal VM’s that I 
use to build the FreeDOS release media. It is possible I broke 
something there a while back and didn’t notice. Or, changes to 
openSUSE broke something there. Or, possible there is some issue with 
one of the packages “unstable” branch”. So, I simply disabled verbose 
output and tried again.


Ran: *make clean*

Edited custom.cfg and re-disabled verbose output.

Ran: *make*

/(waited a while watching build process)/
/
/
Result, Successful Build of a “Interim Build”

In conclusion, there is an unrelated issue regarding “verbose mode” 
during release building process. This is not related to the error you 
encountered. The error you received would most likely have been cause 
by the RBE not getting installed correctly. This could be the result 
of a bad download of the openSUSE operating system. Or possibly, 
something failed during the RBE installation script and the error was 
not caught by that script.


You can try to run the install script for the RBE again. Generally, it 
checks the state of the system and only changes things when needed. 
Primarily, that is because when I make major changes to the RBE, the 
install script can just be run again to “patch up” any new changes 
that are required.


If that does not remedy the problem, I would trash the VM and start 
from the beginning. It could have been a corrupt download of openSUSE.


Left me know if this helped and fixes the build issue you had.

Thanks,

Jerome






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd,

So…

I booted the (Windows 10) machine that I use for creating FreeDOS builds. (Host 
OS should not be relevant.)

There was an update to VirtualBox. So, I installed that and the related new 
extension pack.

( Following the instructions in the RBE’s Wiki. Except for CPU’s, I went with 2 
cores for a reduced build time. )

I created a new VM for the RBE. 

I download a fresh copy of openSUSE 15.5 Leap DVD install for x86. (newest 
version)

( I had a little trouble downloading openSUSE. My home internet was recently 
upgraded to a 1Gb connection. With the standard mirror, I would download for a 
few seconds at very fast rate. Then just stop at some point. After switching to 
a different mirror, it downloaded without problem. It makes me wonder if the 
first server was having issues with the much faster rate. Possibly, it 
considered it a DDOS. But, it could just be Windows. After all, I was having 
issues pulling up GitLab on that machine and no issues on the Mac sitting next 
to it. Then again, maybe since the new router fully supports IPv6, IDK. Only a 
couple days since the upgrade and this was the only time I’ve had an issue. 
Time will tell. )

I installed openSUSE. 

(Note: I need to update wiki. Earlier versions of the openSUSE defaulted to 
activating online repositories. Now you have to choose. They need to be enabled 
for the install script to fetch additional required packages. Otherwise, I used 
my normal location settings and such. Finally (per wiki instructions), I 
selected the system role as server.)
 
After the install of openSUSE, I continued to the Install Builder Tools page in 
the wiki.

Used zypper to install git: git sudo zypper install git

Cloned RBE project: git clone https://gitlab.com/FreeDOS/OS/builder.git

Moved to the Builder directory: cd builder

Ran the install script for the RBE: sudo ./install

Rebooted. (End of wiki)

Logged in as normal user and changed dir to the builder dir.

Ran: make

(waited a while watching build process)

Result, Successful Build of a “Standard Release”

Ran: make clean

Edited custom.cfg to:

unstable=yes
verbose=yes

Ran: make

(waited a while watching build process)

Result, Build failed from unknown issue while creating bootable floppy. 
However, I never use verbose mode in the normal VM’s that I use to build the 
FreeDOS release media. It is possible I broke something there a while back and 
didn’t notice. Or, changes to openSUSE broke something there. Or, possible 
there is some issue with one of the packages “unstable” branch”. So, I simply 
disabled verbose output and tried again. 

Ran: make clean

Edited custom.cfg and re-disabled verbose output.

Ran: make

(waited a while watching build process)

Result, Successful Build of a “Interim Build”

In conclusion, there is an unrelated issue regarding “verbose mode” during 
release building process. This is not related to the error you encountered. The 
error you received would most likely have been cause by the RBE not getting 
installed correctly. This could be the result of a bad download of the openSUSE 
operating system. Or possibly, something failed during the RBE installation 
script and the error was not caught by that script. 

You can try to run the install script for the RBE again. Generally, it checks 
the state of the system and only changes things when needed. Primarily, that is 
because when I make major changes to the RBE, the install script can just be 
run again to “patch up” any new changes that are required. 

If that does not remedy the problem, I would trash the VM and start from the 
beginning. It could have been a corrupt download of openSUSE.

Left me know if this helped and fixes the build issue you had.

Thanks, 

Jerome




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi,

> On Feb 11, 2024, at 7:43 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Hi Jerome,
> 
> it currently fails at:
> 
> tools/common: line 1075: make-dosfs: command not found
> 
> I am currently searching for the make-dosfs executable.//It is not under the 
> builder directory, and I have not found it as an external command in the open 
> suse package repo. Can you confirm that this is part of RBE itself?
> 
> Bernd

Yes, it uses that utility. 

I’ll create a fresh VM using the latest version of openSUSE later today and 
figure out what I need to change to make it compatible (again).

Hopefully won’t take too long. 

Thanks,

Jerome

> 
> 
>> On 11.02.2024 21:09, Jerome Shidel via Freedos-devel wrote:
>> Hi Bernd,
>> 
 On Feb 11, 2024, at 2:11 PM, Bernd Böckmann via Freedos-devel 
  wrote:
>>> 
>>> Hi Jerome,
>>> 
>>> thanks for the explanations!
>>> 
> Am 10.02.2024 um 00:18 schrieb Jerome Shidel via Freedos-devel 
> :
 Oh BTW... If your interested in seeing the RBE in action, or making builds 
 locally, it’s very easy to install and create builds. You can read the 
 instructions for installation into a virtual machine at 
 https://gitlab.com/FreeDOS/OS/builder/-/wikis/home
 
 It’s been a while since I did a fresh install of the RBE. So, hopefully 
 newer versions of the OS that runs the RBE haven’t broken the install or 
 build process.
>>> I have setup an Open SUSE 15.5 container on my Proxmox server. When I have 
>>> the RBE running on it I will try to make the required changes for HTMLHELP 
>>> to be the default help viewer.
>>> 
>>> Bernd
>>> 
>> Great.
>> 
>> You said “when I get the RBE running”… Did you run into an issue under the 
>> latest version of openSUSE that I need to address?
>> 
>> Once the RBE is installed (and working), generating a OS build should be 
>> easy. Simple running “make” then wait.
>> 
>> Of course, there is also a “make clean” to purge all the cached data and 
>> prep for a fresh build.
>> 
>> Very easy to tell the RBE to build ether a “interm test” or “release” build. 
>> It’s just a configuration option.
>> 
>> It even uses custom “user configuration” files. That way, updates to the RBE 
>> itself don’t overwrite build customization. It’s been a while since I 
>> modified any configuration stuff for the RBE. So, I’ll need to check and let 
>> you know the file name. Personally, I just use two different VMs. One for 
>> Interim and one Release Builds. Then I don’t need to mess with changing the 
>> configuration at all.
>> 
>> You’ll just need to set it for Interm Builds. That way it pulls from the 
>> unstable repository branches.
>> 
>> Side notes…
>> 
>> If you set it to “verbose”, it will display a lot of additional information 
>> on what is happening during the build process.
>> 
>> Also, many parts of the build are multi-threaded. So, it is possible adding 
>> cores to the VM “could” result in faster builds.
>> 
>> Someday, I should cross compile a version of SLICER to run under Linux. That 
>> would boost creating the Floppy Edition a great deal.
>> 
>> :-)
>> 
>> Jerome
>> 
>> 
>>> 
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>> 
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP

[Bernd Böckmann via Freedos-devel]

Hi Jerome,

it currently fails at:

tools/common: line 1075: make-dosfs: command not found

I am currently searching for the make-dosfs executable.//It is not under 
the builder directory, and I have not found it as an external command in 
the open suse package repo. Can you confirm that this is part of RBE itself?


Bernd


On 11.02.2024 21:09, Jerome Shidel via Freedos-devel wrote:

Hi Bernd,


On Feb 11, 2024, at 2:11 PM, Bernd Böckmann via Freedos-devel 
 wrote:

Hi Jerome,

thanks for the explanations!


Am 10.02.2024 um 00:18 schrieb Jerome Shidel via Freedos-devel 
:

Oh BTW... If your interested in seeing the RBE in action, or making builds 
locally, it’s very easy to install and create builds. You can read the 
instructions for installation into a virtual machine at 
https://gitlab.com/FreeDOS/OS/builder/-/wikis/home

It’s been a while since I did a fresh install of the RBE. So, hopefully newer 
versions of the OS that runs the RBE haven’t broken the install or build 
process.

I have setup an Open SUSE 15.5 container on my Proxmox server. When I have the 
RBE running on it I will try to make the required changes for HTMLHELP to be 
the default help viewer.

Bernd


Great.

You said “when I get the RBE running”… Did you run into an issue under the 
latest version of openSUSE that I need to address?

Once the RBE is installed (and working), generating a OS build should be easy. 
Simple running “make” then wait.

Of course, there is also a “make clean” to purge all the cached data and prep 
for a fresh build.

Very easy to tell the RBE to build ether a “interm test” or “release” build. 
It’s just a configuration option.

It even uses custom “user configuration” files. That way, updates to the RBE 
itself don’t overwrite build customization. It’s been a while since I modified 
any configuration stuff for the RBE. So, I’ll need to check and let you know 
the file name. Personally, I just use two different VMs. One for Interim and 
one Release Builds. Then I don’t need to mess with changing the configuration 
at all.

You’ll just need to set it for Interm Builds. That way it pulls from the 
unstable repository branches.

Side notes…

If you set it to “verbose”, it will display a lot of additional information on 
what is happening during the build process.

Also, many parts of the build are multi-threaded. So, it is possible adding 
cores to the VM “could” result in faster builds.

Someday, I should cross compile a version of SLICER to run under Linux. That 
would boost creating the Floppy Edition a great deal.

:-)

Jerome




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd,

> On Feb 11, 2024, at 2:11 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Hi Jerome,
> 
> thanks for the explanations!
> 
>>> Am 10.02.2024 um 00:18 schrieb Jerome Shidel via Freedos-devel 
>>> :
>> 
>> Oh BTW... If your interested in seeing the RBE in action, or making builds 
>> locally, it’s very easy to install and create builds. You can read the 
>> instructions for installation into a virtual machine at 
>> https://gitlab.com/FreeDOS/OS/builder/-/wikis/home
>> 
>> It’s been a while since I did a fresh install of the RBE. So, hopefully 
>> newer versions of the OS that runs the RBE haven’t broken the install or 
>> build process.
> 
> I have setup an Open SUSE 15.5 container on my Proxmox server. When I have 
> the RBE running on it I will try to make the required changes for HTMLHELP to 
> be the default help viewer.
> 
> Bernd
> 

Great.

You said “when I get the RBE running”… Did you run into an issue under the 
latest version of openSUSE that I need to address?

Once the RBE is installed (and working), generating a OS build should be easy. 
Simple running “make” then wait.

Of course, there is also a “make clean” to purge all the cached data and prep 
for a fresh build. 

Very easy to tell the RBE to build ether a “interm test” or “release” build. 
It’s just a configuration option. 

It even uses custom “user configuration” files. That way, updates to the RBE 
itself don’t overwrite build customization. It’s been a while since I modified 
any configuration stuff for the RBE. So, I’ll need to check and let you know 
the file name. Personally, I just use two different VMs. One for Interim and 
one Release Builds. Then I don’t need to mess with changing the configuration 
at all. 

You’ll just need to set it for Interm Builds. That way it pulls from the 
unstable repository branches.

Side notes…

If you set it to “verbose”, it will display a lot of additional information on 
what is happening during the build process.

Also, many parts of the build are multi-threaded. So, it is possible adding 
cores to the VM “could” result in faster builds. 

Someday, I should cross compile a version of SLICER to run under Linux. That 
would boost creating the Floppy Edition a great deal. 

:-)

Jerome


> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP

[Bernd Böckmann via Freedos-devel]

Hi Jerome,

thanks for the explanations!

> Am 10.02.2024 um 00:18 schrieb Jerome Shidel via Freedos-devel 
> :
> 
> Oh BTW... If your interested in seeing the RBE in action, or making builds 
> locally, it’s very easy to install and create builds. You can read the 
> instructions for installation into a virtual machine at 
> https://gitlab.com/FreeDOS/OS/builder/-/wikis/home
> 
> It’s been a while since I did a fresh install of the RBE. So, hopefully newer 
> versions of the OS that runs the RBE haven’t broken the install or build 
> process.

I have setup an Open SUSE 15.5 container on my Proxmox server. When I have the 
RBE running on it I will try to make the required changes for HTMLHELP to be 
the default help viewer.

Bernd



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd,

> On Feb 9, 2024, at 3:00 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Hello,
> 
> I uploaded Willis recent changes containing the HTML help 1.1.0 (English) to 
> the unstable Gitlab repo [1]. The other languages are still shipped in 
> version 1.0.8. This also contains version 5.3.6 of the HTMLHELP.EXE with 
> several bugs fixed. Crashes and display corruptions should hopefully not 
> occur anymore.

Awesome! Thanks.

> 
> Can someone please alter the interim build process, so that HTMLHELP is the 
> default help viewer, and this gets a little testing? I would do it by myself 
> but have no overview over the build process and probably not the permissions 
> needed.

The build process used by RBE (Release Build Environment) is a rather complex 
spaghetti monster. But, it is fully automated and minor changes like this are 
fairly easy to implement. 

When the RBE is putting together the Interim Test Build release, it pulls the 
lists of packages for the different media from the two installer projects on 
GitHub. 

Primary Installer Settings:
https://github.com/shidel/FDI/tree/master/SETTINGS 

(or, the unstable branch if it exists)
https://github.com/shidel/FDI/tree/unstable/SETTINGS 


Floppy Edition Settings:
https://github.com/shidel/FDI-x86/tree/master/SETTINGS 
 
(or, the unstable branch if it exists)
https://github.com/shidel/FDI-x86/tree/unstable/SETTINGS 


(unlike Version Release Builds that always pull from the master branch, Test 
builds always pull from unstable branches when they exist)

So, the first step is to verify that the Package for HTMLHELP is included in 
the release and installed. 

The two sets of package lists are similar. But, have a couple big differences. 

The sets from the Primary Installer include simple expansion macros. For 
example, the PKG_FULL.LST includes a $PKG_BASE$ macro. That tells the installer 
to also include everything in the PKG_BASE.LST file. 

So for main installer, it would probable be good to install it with BASE and 
have it “Live” on the LiveCD. A minor change to PKG_BASE.LST. Since, the LiveCD 
always tries to make all the packages in BASE live, no change will be needed to 
the PKG_LIVE.LST. 

( the current PKG_BASE.LST has a reference to HTMLHELP commented out. just need 
to uncomment it for inclusion during install )

The Floppy Edition package lists are a little different. There is only a “BASE” 
for the install called X86_ALL.LST. It does not have any macros. But, it does 
contain platform specific switches for creating the install media archive. 
Those switches resemble comments with a “tag” direction. Individual tags are 
turned off and on in the list file. It starts by turning all tags on. Then, 
when software is not compatible with specific hardware, that tag is turned off. 

Since HTMLHELP should run on the lowest supported hardware, It would be in 
section with most of the BASE packages. 

( note: there is an old reference to base\help commented out. When AMBHELP was 
added, the package for “help” was renamed to htmlhelp)

Once HTMLHELP has been added to the install list, AMBHELP and probably AMBREAD 
should be commented out for the floppy version. Possibly for the main installer 
package list as well.

That will take care of making sure new test version of  HTMLHELP gets installed 
in the next interim build. 

But, there is one more thing we may wish to do…

We probably want to update the HELP.BAT file to prefer HTMLHELP over AMBHELP. 
That will require simply updating the HELP.BAT file in the FDHELPER package on 
GitLab. https://gitlab.com/FreeDOS/base/fdhelper/-/tree/unstable/BIN 


All fairly simple to do. 

If you want to issue some pull requests with the changes thats fine. 

Otherwise, I’ll get to it sometime over the next few days. 

:-)

Jerome

Oh BTW... If your interested in seeing the RBE in action, or making builds 
locally, it’s very easy to install and create builds. You can read the 
instructions for installation into a virtual machine at 
https://gitlab.com/FreeDOS/OS/builder/-/wikis/home 


It’s been a while since I did a fresh install of the RBE. So, hopefully newer 
versions of the OS that runs the RBE haven’t broken the install or build 
process. 



> 
> Thanks! Bernd
> 
> [1] 
> https://gitlab.com/FreeDOS/base/htmlhelp/-/commit/621b781ee2bedc777dcf6f2c86065002f6d48000
> 
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net

[Freedos-devel] HTMLHELP

[Bernd Böckmann via Freedos-devel]

Hello,

I uploaded Willis recent changes containing the HTML help 1.1.0 
(English) to the unstable Gitlab repo [1]. The other languages are still 
shipped in version 1.0.8. This also contains version 5.3.6 of the 
HTMLHELP.EXE with several bugs fixed. Crashes and display corruptions 
should hopefully not occur anymore.


Can someone please alter the interim build process, so that HTMLHELP is 
the default help viewer, and this gets a little testing? I would do it 
by myself but have no overview over the build process and probably not 
the permissions needed.


Thanks! Bernd

[1] 
https://gitlab.com/FreeDOS/base/htmlhelp/-/commit/621b781ee2bedc777dcf6f2c86065002f6d48000





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP progress report

[Bernd Böckmann via Freedos-devel]

Hi Eric,

> How much faster are Unicode and HTML entity translation now?

The speed up of the table lookup is about factor 3. However, there are still 
some bottlenecks in the tag / entity substitution code (not the UTF to codepage 
translation). The code makes heavy use of memmove and realloc, doing the 
substitutions in-place. I have some ideas how to speed this up further.

Fritz Müller also observed that the scrolling and navigation is laggy if the 
documents contain many links. So this is also an area for improvement.

> I would NOT remove the ZIP feature, because a typical help zip
> contains more than 100 files, with a median length of just 1 kB
> uncompressed. This would waste a lot of disk space with large
> clusters and DOS itself also is slow with large directories.

The wasted space resulting from many files and large cluster sizes also came 
into my mind,  and it was one of several reasons which made me propose 
switching to the .PAK container format. But I understand that this file format 
might be too exotic, and delivering the FreeDOS help as an uncompressed ZIP 
might be a good compromise.

> Maybe the search could avoid reopening the zip many times?

I see no reason why this should not be possible, and will put it on my list for 
one of the next interim releases.

> If you want less unpack-overhead, you could even concat
> the help texts after the binary in some way and then UPX it.
> We have tools for similar tricks in FreeCOM, I believe. As
> help is small, everything could fit in RAM after loading.

Sadly the help texts are not that small, accumulating to over a megabyte for 
the FreeDOS help. So one had to resort to XMS or another technique to hold it 
in RAM. Probably not worth the effort. HTMLHELP itself is also heavy on memory 
consumption, being the reason I would like to get rid of the included ZIP code 
and strip everything out not strictly needed :-) But under the light of 
htmlhelp being a generic viewer I now think to better not do it.

> I would not store Unicode translation tables in a central
> place. Maybe you could share tables already used by another
> app or driver in some way, but this is too exotic to have
> a central component a la ICONV or RECODE, I believe.

Yes, maybe. There are also different strategies in doing it, leading to 
different tables. For example HTMLHELP is currently restricted to doing 
character to character conversions, and it can not handle character to 
multi-character conversions (useful when translating emojis etc.).

> You already wanted to check different strategies for tables,
> so maybe you can come up with an encoding which is both good
> for speed and for memory footprint?

I think you are referring to my thoughts if it is possible to optimize the 
translation string table memory consumption for doing language translations, 
especially getting rid of the original language strings compiled into the 
binary. I have some possible solutions in my mind, but DOS purists are gonna 
hate me for the most technically exciting of them (to me) :-) It basically 
boiles down to abusing the NE file format and existing toolchain ecosystem. 
Translation tables go into string resources, the default MZ stub is replaced by 
a custom loader doing the relocation etc. But that’s another topic...

> I think it is good that HTMLHELP can be used as generic
> viewer for simple HTML hypertext packages, either in ZIP
> or as individual files, so I also think that it is good
> that it can handle HTML entities and Unicode on the fly.

Agreed.

> 
> AMB probably goes the other direction: Files have to be
> pre-compiled with extra tools, but the viewer is small.

Yes, fine piece of software. In my opinion does its job as a FreeDOS help 
viewer very well.

Greetings, Bernd



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] HTMLHELP progress report

[Eric Auer]

Hi Bernd,

thanks for all those fixes in HTMLHELP!

How much faster are Unicode and HTML entity translation now?

I would NOT remove the ZIP feature, because a typical help zip
contains more than 100 files, with a median length of just 1 kB
uncompressed. This would waste a lot of disk space with large
clusters and DOS itself also is slow with large directories.

You can try whether it helps to use UNCOMPRESSED ZIP or TAR
and of course nobody complains about benchmarks either. As
far as I remember, HTMLHELP supports both ZIP and unzipped
contents of the ZIP as input, so comparing both modes should
be easy even without code changes :-)

Maybe the search could avoid reopening the zip many times?

If you want less unpack-overhead, you could even concat
the help texts after the binary in some way and then UPX it.
We have tools for similar tricks in FreeCOM, I believe. As
help is small, everything could fit in RAM after loading.

I would not store Unicode translation tables in a central
place. Maybe you could share tables already used by another
app or driver in some way, but this is too exotic to have
a central component a la ICONV or RECODE, I believe.

You already wanted to check different strategies for tables,
so maybe you can come up with an encoding which is both good
for speed and for memory footprint?

I think it is good that HTMLHELP can be used as generic
viewer for simple HTML hypertext packages, either in ZIP
or as individual files, so I also think that it is good
that it can handle HTML entities and Unicode on the fly.

AMB probably goes the other direction: Files have to be
pre-compiled with extra tools, but the viewer is small.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] HTMLHELP progress report

[Bernd Böckmann via Freedos-devel]

Hi,

the last week I worked on HTMLHELP fixing various bugs, and initial tests by 
Fritz Müller and me give hope that the crashes and display corruptions are 
gone. The changes made so far, which will make it into the next FreeDOS interim 
build, are:

  ! Fix a heap corruption bug leading to crashes and display artifacts
  ! Fix stack overflow in full text search leading to program crash
  ! Fix a crash caused by a stack corruption bug in fnsplit function
  ! Fix a crash caused by a stack corruption bug in search GUI function
  ! Fix integer overflow bug in vertical scroll bar display code
  ! Fix UTF to CP 857 conversion table entry for unicode codepoint 0x11F
  ! Fix UTF to CP 852 conversion table entry for unicode codepoint 0x179
  * Display currently searched file while performing full text search
  * Add several HTML entities to substitution table
  * Add support for codepages 775, 848, 849, 1125, 1131
  ~ Speed up unicode to codepage translation
  ~ Speed up HTML entity substitution
  ~ Changed default calling convention from C to Watcom

There are still many parts of the software which can be improved. The most 
urgent one is the barely usable full-text search, which it is really slow. It 
is slow because HTMLHELP stores its files in a compressed ZIP archive, and 
doing a full-text search inside a compressed archive on an old machine is not 
lightening fast, especially if you reopen the ZIP file a few hundred times 
while doing the search.

I would like to throw out all the ZIP functionallity (20Kb), and bring the size 
of the code segment down to under 64K, enabling using the compact memory model. 
But for ease of use HTMLHELP should continue letting the help author ship the 
help files within some form of container format. Call me crazy, but the most 
simple solution would be using the .PAK container format used by the Quake 3D 
engine. An implementation can be done in around 100 LOC. See 
https://quakewiki.org/wiki/.pak 

If no one intervenes I would like to do a proof of concept implementation to 
see how it performs.

A second area that needs improvement is the unicode to codepage translation. 
While this works reasonably well now, the increasing number of conversion 
tables linked into the binary is becoming a real memory waster. Obvious 
solution would be to throw them out of the binary, and only load the needed 
translation table from an external file. Which leads to the next question: 
Should these tables be stored in a central, well defined directory within 
FreeDOS, accessible to all programs doing this translation stuff? There is 
little to no need for every program to reinvent this wheel. Perhaps such a 
general solution already exists?

Happy to get feedback,
Bernd








___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] HTMLHELP

[Andy Stamp]

Hello,

Fritz pinged me about possibly making updates to fix some HTMLHELP bugs,
but I wasn't sure if it was going to continue to be included with the
distribution.

I'm happy to try to resolve issues with the project if it is worth my time.

I submitted a merge request here for whomever is a maintainer to fix a
crash issue with &-entities in  tags.
https://gitlab.com/FreeDOS/base/htmlhelp/-/merge_requests/2

I sent Fritz a binary off-list to test and will try to poke at his original
list of issues.

Cheers,
-- 
--Andy
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] htmlhelp bug list

[Eric Auer]

Hi Andy,

nice to hear that you are working on improving HTMLHELP.

If you ask me, it would be great to keep a working HTML
based help viewer around. The format has the advantage
that people already know HTML and can contribute content
and translations easily. AMB converted versions are nice
to have as well, of course, but the orginal version is
good and convenient for http://help.fdos.org/ and simple
to read from your Windows or Linux on another disk or PC.

I have not compared the features of both tools, so if you
say AMB preserves all style and user interface possibilities
and is easy to maintain and convert to from HTML, it may
be an option to drop the DOS HTML viewer if that is too
hard to port to OpenWatcom. But it certainly is good to
have the content itself available in HTML format.

Regards, Eric



> Hello,
> 
> I started working on getting HTMLHELP building with OpenWatcom because I
> don't have access to Borland C++ 3.1 in preparation for fixing some bugs.
> This was around the same time that Mateusz released the AMB format and
> converted the FreeDOS help HTML files to that format.
> 
> Should I continue on this effort or will AMB replace the existing HTMLHELP
> system?
> 
> --Andy




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] htmlhelp bug list

[Andy Stamp]

Hello,

I started working on getting HTMLHELP building with OpenWatcom because I
don't have access to Borland C++ 3.1 in preparation for fixing some bugs.
This was around the same time that Mateusz released the AMB format and
converted the FreeDOS help HTML files to that format.

Should I continue on this effort or will AMB replace the existing HTMLHELP
system?

--Andy

On Tue, Feb 2, 2021 at 3:39 PM Eric Auer  wrote:

>
> Hi Tom,
>
> Of course I meant Fritz Mueller who does have a lot
> of experience in using HTMLHELP and working with help
> texts for it. So I trust him that those bugs do exist.
> He just is not on the mailing list, so I am forwarding.
>
> You wondered whether bugs depend on configuration: One
> of the bugs is that if LANG=XX is set and no htmlhelp.XX
> translation exists, the HELP exe hangs instead of just
> using no translation. That does depend on configuration
> but it could fail more gracefully.
>
> >> b) help.exe often crashes when moving around from index.htm to
> >> sub-htm-files and back or from one sub-htm-file to other ones
> >> and back.  In many cases you have to reboot.
>
> > in case of 'often' it would be helpful to have examples of this
>
> That should be quantified better, yes.
>
> >> d) Referring to c): There is one more problem: At some files you
> >> can move down with arrow up/down to this end (last shown line).
> >> When you do so there are WRONG links shown THAT HAVE ABSOLUTELY
> >> NOTHING TO DO with the actual htm file (no idea where help gets
> >> them from). Sometimes this are correct links like
> >> "hhstndrd/command/set.htm", sometimes only absolute nonsense
> >> is shown at the left bottom. If you type "ENTER" the htm file
> >> may be executed or you get an error message. that e.g.
> >> "xyzcba_?DIR" cannot be found.
>
> That does indeed need a specific example.
>
> >> e) I created an internet version where special characters,
> >> german Umlauts and french/spanish accents can be written
> >> as e.g. "". It is supported by help and Mateusz
> >> Viste created his amb files out of it, but not when such
> >> characters are written in the " special character"
> >> header section. In this case help hangs.
>
> Fritz and Mateusz, where can the web version be downloaded?
>
> And Tom, as you know, Fritz is no DOS programmer. So while
> it is cool that HTMLHELP is open source, he cannot fix it.
> Some people may still find reading his bug reports useful.
>
> Eric
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>


-- 
--Andy
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] htmlhelp bug list

[Eric Auer]

Hi Tom,

Of course I meant Fritz Mueller who does have a lot
of experience in using HTMLHELP and working with help
texts for it. So I trust him that those bugs do exist.
He just is not on the mailing list, so I am forwarding.

You wondered whether bugs depend on configuration: One
of the bugs is that if LANG=XX is set and no htmlhelp.XX
translation exists, the HELP exe hangs instead of just
using no translation. That does depend on configuration
but it could fail more gracefully.

>> b) help.exe often crashes when moving around from index.htm to
>> sub-htm-files and back or from one sub-htm-file to other ones
>> and back.  In many cases you have to reboot.

> in case of 'often' it would be helpful to have examples of this

That should be quantified better, yes.

>> d) Referring to c): There is one more problem: At some files you
>> can move down with arrow up/down to this end (last shown line).
>> When you do so there are WRONG links shown THAT HAVE ABSOLUTELY
>> NOTHING TO DO with the actual htm file (no idea where help gets
>> them from). Sometimes this are correct links like
>> "hhstndrd/command/set.htm", sometimes only absolute nonsense
>> is shown at the left bottom. If you type "ENTER" the htm file
>> may be executed or you get an error message. that e.g.
>> "xyzcba_?DIR" cannot be found.

That does indeed need a specific example.

>> e) I created an internet version where special characters,
>> german Umlauts and french/spanish accents can be written
>> as e.g. "". It is supported by help and Mateusz
>> Viste created his amb files out of it, but not when such
>> characters are written in the " special character"
>> header section. In this case help hangs.

Fritz and Mateusz, where can the web version be downloaded?

And Tom, as you know, Fritz is no DOS programmer. So while
it is cool that HTMLHELP is open source, he cannot fix it.
Some people may still find reading his bug reports useful.

Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] htmlhelp bug list

[tom ehlert]

> To whom it may concern: Current issues with HTMLHELP from Fritz :-)

why do we accept input from 'Fritz' who wants to remain anonymous?

did you verify these bugs?
or could this be dependend on the Fritz's configuration?
what version of HTMLHELP with what version of help files?

> a) If there is a language set in environment variables, e.g.
> "set LANG=ID" and there is NO "htmlhelp.ID"
> help hangs instead of working and  falling back to english language,
seems genuine enough to be reproducible

> b) help.exe often crashes when moving around from index.htm to
> sub-htm-files and back or from one sub-htm-file to other ones
> and back.  In many cases you have to reboot.
in case of 'often' it would be helpful to have examples of this

> c) At different files the htm files show up to 10 empty lines below
> the end line ("after:  although there is max 1
> empty line below in the file. This looks ugly.
should be findable.

> d) Referring to c): There is one more problem: At some files you
> can move down with arrow up/down to this end (last shown line).
> When you do so there are WRONG links shown THAT HAVE ABSOLUTELY
> NOTHING TO DO with the actual htm file (no idea where help gets
> them from). Sometimes this are correct links like
> "hhstndrd/command/set.htm", sometimes only absolute nonsense
> is shown at the left bottom. If you type "ENTER" the htm file
> may be executed or you get an error message. that e.g.
> "xyzcba_?DIR" cannot be found.

'At some files': would be cool to know what files.

> e) I created an internet version where special characters,
> german Umlauts and french/spanish accents can be written
> as e.g. "". It is supported by help and Mateusz
> Viste created his amb files out of it, but not when such
> characters are written in the " special character"
> header section. In this case help hangs.

wow. why are you posting about 'I created an internet version'
without giving instructions how to get 'I created an internet version'


> f) I am sure there are more but I would be happy if at least
> these problems could be fixed.

thanks for the bug list, but realistically: HTMLHELP is open source. just fix 
it yourself.


> Fritz
Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] htmlhelp bug list

[Eric Auer]

Hi!

To whom it may concern: Current issues with HTMLHELP from Fritz :-)

a) If there is a language set in environment variables, e.g.
"set LANG=ID" and there is NO "htmlhelp.ID"
help hangs instead of working and  falling back to english language,

b) help.exe often crashes when moving around from index.htm to
sub-htm-files and back or from one sub-htm-file to other ones
and back.  In many cases you have to reboot.

c) At different files the htm files show up to 10 empty lines below
the end line ("after:  although there is max 1
empty line below in the file. This looks ugly.

d) Referring to c): There is one more problem: At some files you
can move down with arrow up/down to this end (last shown line).
When you do so there are WRONG links shown THAT HAVE ABSOLUTELY
NOTHING TO DO with the actual htm file (no idea where help gets
them from). Sometimes this are correct links like
"hhstndrd/command/set.htm", sometimes only absolute nonsense
is shown at the left bottom. If you type "ENTER" the htm file
may be executed or you get an error message. that e.g.
"xyzcba_?DIR" cannot be found.

e) I created an internet version where special characters,
german Umlauts and french/spanish accents can be written
as e.g. "". It is supported by help and Mateusz
Viste created his amb files out of it, but not when such
characters are written in the " special character"
header section. In this case help hangs.

f) I am sure there are more but I would be happy if at least
these problems could be fixed.

Fritz



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] HTMLHELP English Proofreading

[Steve Owens]

Hi -

I can help with the English proofreading for HTMLHELP if you still need
someone. I am a senior technical writer/editor.

- Steve
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] HTMLHelp maintainer and copyright

[Robert Platt]

Hello,

I notice my name is still listed for the various help
projects. However, I left the FreeDOS project around
last October and you won't get a new maintainer unless
you advertise!

I've updated the website to reflect the situation.
Please remove my name and email address from the
software list. 

Please note I no longer read emails to this address;
therefore, so that FreeDOS will be able to protect its
interests, I wish to make the following copyright
assignment:

I hereby declare that those copyrights dated the year
2004 or before held in my name for the source code and
documentation and html help files of any part of
HTMLHelp, Whatis/Apropos for FreeDOS, Fasthelp and
Undelete, and only for those express items, shall be
transferred entirely to Jim Hall of the FreeDOS
project. This includes the right to subsequently
transfer copyright to someone else. The transfer of
rights to Jim Hall comes into effect immediately,
regardless of when the copyright notices are modified.
I shall not be responsible for modifying the copyright
notices.
Rob Platt, 23 April 2005

Although a signed letter would be ideal, I believe
this transfer to be legally useful and will help Jim
protect all the stuff I've contributed.

All the best for the future!
Rob


Send instant messages to your online friends http://uk.messenger.yahoo.com 


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] HTMLHELP Crashes with DOS=HIGH

[tom ehlert]

Hello Bernd,

just tested HTMLHELP with ke2035+ (toms boring stable version).

AFAICT, everything works fine. no crashes,...

sorry bernd: thanks for the crashing boot disk, but I somhow managed
to loose it in cyberspace.

you might resend me a  crashing version ;)

tom






---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel