ANNOUNCE: DJGPP port of FSU Pthreads 3.14 uploaded.

[Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp-announce@delorie.com]]

This is a port of FSU Pthreads 3.14 to MSDOS/DJGPP.

FSU Pthreads is a prototype implementation of POSIX 1003.1c. It is a
C-language library that supports multiple threads of control within a
single process. It does not implement the entire Pthreads interface but
it does provide some of the capability of the POSIX 1003.1 base standard
and POSIX 1003.4 Real-Time Extensions.


DJGPP specific changes.
=======================

- The code of the library is almost 20 years old, thus a lot of the coding
syntax used choke modern versions of gcc. Here some fixes were required.
Also DJGPP has changed during the last 20 years, thus some adjustments
were required to get it compiled. Especially the fact that neither the
definition sigset_t nor jmp_buf used by DJGPP nowadays does fully match
the assumptions made in library code, makes it necessary to adjust it.
Details are not worth to be explained; if really interested look at the
diffs file. It is divided in three parts: the first part describes the
syntax error fixes, the second one describes the warning fixes and the
third part discribes the DJGPP specific changes.

- The library code offers some degree of debug support. This code has not
been ported. It may work or not. If it does not work you are alone to
fix the DJGPP specific part. As a starting point look at the "tdi" dir.
It is supposed to make gdb usable with threaded code, but due to age of
the library I do not know if today's versions of gdb will work with this
"tdi" interface. I do not have neither the knowledge nor time to fix or
implement this support.

- The code offers no testsuite thus it has only be tested by using it
building other ports that depend on a threading library.

- The code offers no man pages nor other type of documentation in some
standard reader format. Thus read the REA>DME and ANNOUNCE files
carefully. There may by some more information following the links
offered at:
<http://moss.csc.ncsu.edu/~mueller/pthreads/>
from where the sources have been retrieved.
I have also never verified that any of the mailing list to ask for
assistance or to reporting bugs still do work at all after 20 years.

- The port is intended as an alternative to the GNU POSIX threading port
pth207[b|s].zip. I have not compared their performance and I am not
lobbying to use this one instead of the other one. I have ported this
one to use it in other ports and to make it available to other users.

- The port has been configured and compiled on WinXP SP3 and Win98SE.
There is no guarantee that this may be possible with any other DOS-like
OS. Due to the massive use of long file names it will not be possible
to configure and compile without LFN support.

To build this port you will need an OS with LFN support to configure and
compile the source package.

As usual, all djgpp specific files (diffs, README files, etc.) are stored in
the /djgpp directory. The sources have been configured to be build in the
"src" directory. Compile it by running make.

For further information about FSU Pthreads please read the info docs and NEWS file.



This is a verbatim extract of the ANNOUNCE file:

-------------------------------------------------------------------------------
It is the first DJGPP port of FSU Pthreads. Read the complete ANNOUNCE file.


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




The port consists of the usual three packages produced using djdev205
that can be downloaded from ftp.delorie.com and mirrors as (time stamp 2017-02-22):

FSU Pthreads 3.14 headers and library:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/fpth314b.zip

FSU Pthreads 3.14 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/fpth314s.zip



Send FSU Pthreads specific bug reports to <pthrea...@ada.cs.fsu.edu>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <dj...@delorie.com>.


Enjoy.

Guerrero, Juan Manuel <juan.g...@gmx.de>

[rug...@gmail.com]

Hi,

On Monday, March 6, 2017 at 11:36:28 AM UTC-6, Juan Manuel Guerrero (juan.g...@spam.sux) [via djgpp-a...@spam.sux] wrote:
>
> This is a port of FSU Pthreads 3.14 to MSDOS/DJGPP.
>

> - The code offers no testsuite thus it has only be tested by using it
> building other ports that depend on a threading library.

I don't know anything about threads, so I'm not much help. But ....

A few years ago, one guy (Khusraw) fixed it to build with DJGPP again.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/9.20.1/FSUPthreads314DJ.zip (sources only)

That was primarily used with his (then-current) build of p7zip
(using DJGPP/G++).

I have not tried rebuilding p7zip lately (although another guy recently
built 16.02, but I have no idea of the details).

http://mik.dyndns.pro/dos-stuff/

IIRC, there was also some other threading test suite, which apparently was
used by Minix 2.x (with FSU Pthreads) back in the day:

http://minix1.woodhull.com/pub/contrib/champoll.txt

http://web.archive.org/web/20030317052940/http://atc.unex.es/jdiaz/anatome/contrib/champollion/champollion.html

[Juan Manuel Guerrero]

Thanks for the pointers. I have tried some of the test
programs from champoll.tar.Z and they seem to compile and
to run flawlessly. I have also tried to compile p7zip_9.20.1_src_all.tar.bz2
but I do not have yasm installed thus the build failed.
May be you want to give the port a try.

The only reason why I ported it was that I was trying to
port pkg-config-0.29.1.tar.gz and the include glib requires
among a lot of other libraries also a thread library and in
the end it was easier to port one than to try to rewrite a
single threaded code version of glib. I was aware that
there was already a port of GNU pthreads but it had some
issues IIRC.
Because the FSU pthread library was the second pthread
library available that used to have some DJGPP support
I decided to port it to DJGPP 2.05. May be it is of
some use for someone else.

Regards,
Juan M. Guerrero

[Jim Michaels]

so you are saying it probably won't work on DOS? I would like DOS multithreading. then I could wipe multiple disks in parallel or so special math stuff in parallel or refresh disks in parallel.

[rug...@gmail.com]

Hi,

On Tuesday, March 7, 2017 at 1:58:34 PM UTC-6, Juan Manuel Guerrero wrote:
>
> I have also tried to compile p7zip_9.20.1_src_all.tar.bz2
> but I do not have yasm installed thus the build failed.
> May be you want to give the port a try.

It's been a few years since I bothered with p7zip. I don't
remember all of the details and didn't study my old makefile
closely here. But, IIRC, you don't need YASM at all.

Latest 7-Zip proper is 16.04 (from last October) but 16.02 is
still latest p7zip proper (from last May / ported in July).

https://sourceforge.net/projects/p7zip/files/p7zip/16.02/

Try using this makefile.machine to build p7zip 16.02 :

*** makefile.machine ***
# p7zip 16.02 using DJGPP (+ FSU Pthreads)

ifeq ($(DJGPP),)
$(error Please install/enable DJGPP first!)
endif

OPTIMIZE=-O -mtune=i686 -s
OPTFLAGS=$(OPTIMIZE)

ALLFLAGS=$(OPTFLAGS) \
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE \
-DNDEBUG -D_REENTRANT -DENV_UNIX \
-DETIMEDOUT=110 \
$(LOCAL_FLAGS)

CXX=gpp
CC=gcc

LINK_SHARED=
LOCAL_LIBS_DLL=$(LOCAL_LIBS)
LOCAL_LIBS=-lgthreads

OBJ_CRC32=$(OBJ_CRC32_C)
OBJ_AES=
*** end ***

A quick attempt seems to build okay. I then used that 7za.exe
to unpack/rebuild sources again, and the resulting .EXE is the same.
Try it yourself. ("redir -t" says it took roughly 4 + 1/2 minutes
under DOSEMU.)

> Because the FSU pthread library was the second pthread
> library available that used to have some DJGPP support
> I decided to port it to DJGPP 2.05. May be it is of
> some use for someone else.

IIRC, in older p7zip builds, GNU pth and Watt-32 were used, but
FSU pthreads is standalone, thus smaller binaries. So yes, at
least in this particular case, it's indirectly useful.

[rug...@gmail.com]

Hi,

On Thursday, March 23, 2017 at 7:15:32 PM UTC-5, rug...@gmail.com wrote:
>
> A quick attempt seems to build okay. I then used that 7za.exe
> to unpack/rebuild sources again, and the resulting .EXE is the same.
> Try it yourself. ("redir -t" says it took roughly 4 + 1/2 minutes
> under DOSEMU.)

Trying this again has reminded me of the tradeoffs between various
build methods. I had forgotten that I also cross-compiled with
Ozkan's older 2011 GCC build. So I upgraded that (20160728) and
also applied a very naive patch (since "lite" lacks symlinks):

--- p7zip_16.02.new/CPP/Windows/FileDir.cpp 2015-11-09 09:51:42.000000000 -0600
+++ p7zip_16.02/CPP/Windows/FileDir.cpp 2017-03-28 17:26:10.000000000 -0500
@@ -331,6 +331,7 @@
#endif

static int convert_to_symlink(const char * name) {
+#ifndef DJLITE
TRACEN(printf("LINK(%s)\n",name))
FILE *file = fopen(name,"rb");
if (file) {
@@ -346,6 +347,7 @@
return ir;
}
}
+#endif
return -1;
}
*** end ***

So yes, I can cross-build it, lightning-fast, with "time make -j4"
(2 cores, aka 4 w/ HTT).

Even building in FreeDOS natively under VM isn't horribly slow
with VT-X enabled. But, without VT-X, no thanks, ugh!

[Jim Michaels]

On Monday, March 6, 2017 at 9:36:28 AM UTC-8, Juan Manuel Guerrero (juan.g...@gmx.de) [via djgpp-a...@delorie.com] wrote:

I did an nslookup of ftp.cs.fsu.edu domain and discovered it doesn't exist anymore, but the email does.

[rug...@gmail.com]

Hi,

On Tuesday, April 11, 2017 at 3:46:15 PM UTC-5, Jim Michaels wrote:

> On Monday, March 6, 2017 at 9:36:28 AM UTC-8, Juan Manuel Guerrero (juan.g...@spam.sux) [via djgpp-a...@hates.spam] wrote:
> >
> > This is a port of FSU Pthreads 3.14 to MSDOS/DJGPP.
> >

> > There may by some more information following the links offered at:
> > http://moss.csc.ncsu.edu/~mueller/pthreads/
>

> I did an nslookup of ftp.cs.fsu.edu domain and discovered it doesn't
> exist anymore, but the email does.

Florida State University still exists (apparently):

http://www.cs.fsu.edu/

The far-above (old) link says this:

"funded by: U.S. Army AJPO, awarded to Ted Baker, Florida State University"

The announce refers to "PART (POSIX / Ada-Runtime Project)" and says,
"Copyright (C) 1992-2000 ... FSU ... LGPL".

AFAIK, long ago, there was a slimmed Ada/DJGPP install ("EZ...something")
that was probably intended to use this. I never learned Ada, so I only
looked at it once or twice.

Okay, a quick search rings some bells. Michael Feldman, George
Washington University (GWU), "ez2load", etc.

http://www.mcs.csueastbay.edu/~reiter/3120/free.ada

This is circa 1996 and says, "GNAT version 3.04 for MS-DOS is now
included. This is a _full_ Ada 95 compiler and binder and now supports
tasking. Version 3.04 depends on djgpp version 2 ...."

IIRC, it was using GCC 2.8.1 and possibly mirrored on Simtel.net. But
I don't remember tasking working (and AFAIK doesn't work at all
in any semi-recent DJGPP Ada builds).

Once again, this is not "true" tasking, so DOS is still DOS. (Novell
DOS 7 had some threading/multitasking functionality in its EMM386 [sic],
but no third-party devs ever cared. And that's too old/proprietary for
us anyways.)

[Jim Michaels]

On Monday, March 6, 2017 at 9:36:28 AM UTC-8, Juan Manuel Guerrero wrote:
> This is a port of FSU Pthreads 3.14 to MSDOS/DJGPP.

I discovered that multithreading on DOS might not be a problem - I probably said this once before - the BIOS may have FAN upper and lower temperature limits and speed settings for those. this with the right cooler could solve the problem of burnt cpu (going at or beyond tCASE for too long).

usually the motherboard shuts down the PC when this happens, at least in the case of a laptop. but if the laptop cooler fan is plugged with junk (cat hair?), it would just overheat and stop within 30sec of powerup. hp's compaq laptops seem to be the easiest to open and clean out.

[Jim Michaels]

something that's needed with pthreads are functions that do this:
- available processor count
- total processor count

[Jim Michaels]

can pthreads be wrapped with std::thread please?

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

On 5/10/2017 12:22 AM, Jim Michaels (jmic...@yahoo.com) [via

Dude, what are you talking about? Are you just some very sophisticated
markov bot?

Frank