Mostly this is adding appropriate #includes and declarations,
but for WmImage.c we also change from using the proper name
for XmeGetMask, rather than the identical but renamed
version _DtGetMask which is not exported in any header.
Patch from Pascal Stumpf <Pascal.Stumpf@cubes.de>
The official POSIX name for this signal is SIGCHLD. Linux probably
has SIGCLD only for SysV compatibility, but BSD does not.
Patch from Pascal Stumpf <Pascal.Stumpf@cubes.de>:
So here are all the patches that deal with the fact that modern
compilers assume different scoping rules for variables declared in for
loops. On Linux, -fpermissive has been added as a compiler flag to
compensate for this old C code, but I think it is the wrong approach.
Sorry, couldn't help sneaking in a || defined(CSRG_BASED) and some casts
needed for other reasons ...
Patch from Pascal Stumpf <Pascal.Stumpf@cubes.de>
Most is just copied from the existing imake installation in
/usr/X11R6. Additionally:
* Allow overriding CDESharedRev, X11ProjectRoot and ProjectRoot
* Add a new define to be able to override MINCLUDESRC too
(this allows me to build CDE without symlinking any include directories)
don't use the idiom
char foo[BUFSIZ];
snprintf(foo, BUFSIZ, ....);
but
char foo[BUFSIZ];
snprintf(foo, sizeo foo, ....);
because this will automatically catch situations where the size of foo
is later changed, e.g. like foo[BUFSIZ + 8];
Fix another use of sprintf.
Patch from Robert Tomsick <robert+cde@tomsick.net>:
I believe this fixes vulnerability #3 from CERT CA-1999-11.[1] The other
uses of sprintf in DtAction seem to be safe.
[1] https://www.cert.org/advisories/CA-1999-11.html
Patch from Frederic Koehler <f.koehler427@gmail.com>:
These implicit definitions cause segfaults on x64 because
the implicit return type is a 32-bit signed int, rather than a pointer
type.
Patch from Frederic Koehler <f.koehler427@gmail.com>:
Define a final fallback for loading default window manager font;
before exiting, forcefully try to load "fixed" font. This is sufficient
to allow systems where fontList is set to an empty list to startup dtwm,
for now.
dtlogin's genauth routines were trying to open and read /dev/mem on
linux and (presumably) bsd systems in order to obtain random data used
in creating an auth key.
This is bad for a variety of reasons. Newer linux kernels (at least
on 3.2) issue the following warning to the kernel logs:
"Program dtlogin tried to access /dev/mem between 100000->102000."
Now on linux we will use /dev/urandom, and on CSRG_BASED (bsd) systems
we will use /dev/random to obtain some entropy.
Patch from Ulrich Wilkens <mail@uwilkens.de>
I have a little patch for a problem that I found when I tried to
compile dthelp on 64bit FreeBSD. It could also be a problem on other
64bit systems. The problem is that the program context compiles but
fails running with segmentation fault.
context uses the function m_malloc() which is missing a correct
prototype sometimes. Then it's treated to return int instead of void *
. On 64bit systems this cuts off the higher 32 bits because void * is
64bit whereas int is only 32bit.
Patch from Douglas Mencken <dougmencken@gmail.com>:
The issue is that MESSAGE tries to invoke catgets with NULL first
parameter, which is dereferenced inside catgets (Std C Library
function) without checking, from catgets.c source:
if (catalog->name_ptr[idx + 0] == (u_int32_t) set
&& catalog->name_ptr[idx + 1] == (u_int32_t) message)
On the other hand, there's a special value: -1 (cast to nl_catd),
which must be used instead of 0 (NULL) in the case when we are unable
to provide real catalog_desc, from catgets.c source:
/* Be generous if catalog which failed to be open is used. */
if (catalog_desc == (nl_catd) -1 || ++set <= 0 || message < 0)
return (char *) string;
In dtlogin, you can select the language to switch to by selecting it
via Options->Language. Unfortunately this was also including '.' and
'..', since this list is built dynamically by scanning a directory.
Now we screen out '.' and '..'.
The TOG copyrights were being removed after a rebuild, leaving behind
the scary "RESTRICTED" copyright text that was originally there.
The issue was that the TOG copyrights were not properly embedded
within a 'DTB_USER_CODE_START' code block.
dtcodegen does not preserve any code outside DT_USER_CODE START and
END blocks.
Additionally, these objects are built with -merge by dtcodgen, so the
existing 'RESTRICTED' header within the codeblocks was being retained.
The dtwm DefaultWindowMenu did not list any of the workspace enabled
Occupy commands, which makes it a bit difficult to move windows into a
workspace, or to occupy multiple workspaces.
This was rectified by copying the relevant lines from the
SampleWindowMenu sections containing them that already existed in the
localized files. Tested on C and DE (German).
instant should fail if the locale xlation db cannot be opened.
The reason this was failing was because the locale translation DB for
linux did not exist (Linux.lcx). I didn't add it until weeks/months
later :)
There needs to be one for each platform called "$(uname -s).lcx".
FreeBSD will need one too.
Note, there are still some issues with certain programs appearing not
to use their localized message catalogs properly, while others work
fine.
Also, in order to build these now, you need to make sure you have
installed the DE, ES, FR, and IT locales before building or you will
get failures. On [k]ubuntu, at least, you can install these with the
following commands:
sudo locale-gen de_DE
sudo locale-gen es_ES
sudo locale-gen fr_FR
sudo locale-gen it_IT
In order for this to work, dtsession must be setuid root. If
dtsession is not setuid root, then locking will be disabled, and a
message will be written to ~/.dt/errorlog with the message: "Unable to
lock display due to security restrictions".
Note, this requires that the xfonts-100dpi and
xfonts-100dpi-transcode[d] packages be installed. Kubuntu 11.10 calls
the transcoded package 'xfonts-100dpi-transcoded' while 12.04 calls it
'xfonts-100dpi-transcode'
You can also use the 75dpi variants if you wish, though they will look
crappy on larger monitors (>1024x768).
What we really need are more fonts installed, like all of the xf 75dpi
and 100dpi fonts. 100dpi looks much better than 75/72 dpi, especially
on any display larger than 1024x768. Of course, in the far future, we
should use the anti-aliased TT fonts everyone else uses these days
anyway.
Note, these still aren't quie working yet. Notably, font.dir needs to
be generated properly and re-committed so they will be used.
mkfontdir is used to do this, but currently it fails on these
font.alias files (does not recognize them).
Pascal Stumpf