Formatted text currently gets corrupted by DtTerm when copied into its
history buffer.
As soon as a line of text is copied into the history, the text of each
segment of formatted text is altered so that it contains the text from
the start of the line. For example:
echo -e '\e[1mbold\e[m \e[4munderlined\e[m'
When the text has scrolled off the screen, scrolling back to it reveals:
boldbbold under
This is fixed by adding the calls to _DtTermPrimBufferGetCharacterPointer
that were missing which would update the buffer pointer when inserting
text into the history buffer.
This patch fixes many warnings from the beginning of the build up to
and including the depend stage. Nearly all warnings should be gone
even with -Wall.
The cause of the bug was that X*DrawImageString draws background
according to the extents of the given string, not to extents of the font set,
which determine terminal line height.
Now, when such a situation is detected, the background is cleared before
drawing the characters.
There was a check in linux.cf for the Linux libc version that didn't
work, since these were never set anywhere. Presumably current Xorg
imake sets these, but since we aren't using that... (yet)
As a result, the build assumed that thread-safe API's were not
supported. Setting the default libc major version to '6' allows the
proper build to take place. libc5 was never threadsafe and no one has
probably used it in over 10 years.
As a result, some earlier porting fixes that referenced '__fds_bits'
on linux systems had to be reverted as these are not valid in an MT
environment. They are also not neccessary when building in such an
environment, as the normal 'fds_bits' works fine.
This patch defintely needs testing on many linux systems.
In init() there was code iterating over all of the possible file
descriptors in a svc_fdset. fdsets are limited to FD_SETSIZE. This
caused coredumps on FreeBSD 10, and possibly other hidden issues.
Moving to poll(), rather than select() would be better, but is a bigger
job. For now, just limit to the FD_SETSIZE that select() requires.
Mostly missing headers, explicit parentheses and new prototypes.
Some Caveats:
* I haven't compile-tested the SVR4 getpty file, it might need another tweak
* There were operator precedence bugs in TermPrimCursor.c and TermPrimRender.c
(^ vs. !=). This might change behaviour, but at least I haven't experienced
any crashes ...
* This adds a little more dependencies for include ordering, but unless we
want to play the "headers that include headers that include headers..." game,
this is unavoidable.
Currently, mp_rpc_server.C tries 538 million ports to acquire an
available transient rpcbind port number. This is bad when rpcbind is
running in secure mode (and you are not using tirpc) - Xsession will
'hang' at the dthello (blue) screen filling up your error logs with
RPC errors.
Now, just try +- 50 (for a total of 100 ports) before bailing. The
dthello 'blue screen of death' is the most common problem in starting
CDE when rpcbind isn't set up properly. This should at least not
cause the appearance of a 'hang'.
This adds a basic library and support to dtsession and dtlogin to
support Xinerama/Twinview, where multimple monitors are used to make
up an X11 screen.
The main goal here is to draw dialogs and such centered on a monitor,
rather than spread out over multiple monitors.
Might need to add sorting - as on my test system, what I would
consider monitor 0, appears to actually be monitor 1. So a sort might
need to be added to sort the screens according to increasing x and y
offsets so it make sense to a user.
Also, this library is built statically and not documented. Maybe it
could be 'filled' out and refactored/redesigned in the futre if need
be and suppoerted.
It is enabled via a define, CDE_USEXINERAMA in site.def. It's a very
simple lib, so I do not expect any issues with the BSD's - it should
build and work fine, assuming your X server has the XINERAMA
extension, which I think pretty much all of them do at this point.
This reverts commit 44e384aedb.
This code is actually needed. If svcfd_create() is not available, it
should be fixed only for those systems that it affects.
libDtHelp is unable to read SDL help files
with -ftree-store-ccp optimization which
is enabled by -O2 on gcc 4.2.1.
GifUtils.c and decompress.c didn't work
properly with -ftree-store-ccp enabled.
GifUtils.c was repaired by fixing
those warnings:
GifUtils.c: In function 'create_pixmap':
GifUtils.c:1093: warning: return makes integer from pointer without a cast
GifUtils.c:1110: warning: return makes integer from pointer without a cast
GifUtils.c:1215: warning: return makes integer from pointer without a cast
GifUtils.c: In function 'gif_to_pixmap':
GifUtils.c:1242: warning: return makes integer from pointer without a cast
decompress.c didn't generate warnings, but the
only effect of the -ftree-store-cpp was to introduce
this change:
addq $1, %rax
movq %rax, (%rbx)
.L90:
- cmpl $157, %edx
+ cmpl $-99, %edx
jne .L86
movl 8(%rbx), %eax
subl $1, %eax
Which corresponds to this source code:
bufioI.h
57 #define BufFileGet(f) ((f)->left-- ? *(f)->bufp++ : (*(f)->io) (f))
42 int (*io)(/* BufFilePtr f */);
decompress.c
53 #ifdef NO_UCHAR
54 typedef char char_type;
55 #else
56 typedef unsigned char char_type;
57 #endif /* UCHAR */
58
59 static char_type magic_header[] = { "\037\235" }; /* 1F 9D */
131 if ((BufFileGet(f) != (magic_header[0] & 0xFF)) ||
132 (BufFileGet(f) != (magic_header[1] & 0xFF)))
133 {
134 return 0;
135 }
BufFileGet() returns (int), so the (unsigned char) constants
got promoted to (int) with sign extension; therefore constant
157 decimal (0x9D) became -99 decimal, sign extended
(0xffffff9D), and the comparison was always false.
Tested using:
$ gcc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]
Running on:
FreeBSD 10.0-CURRENT (r240948M)
built Wed Sep 26 23:33:08 CEST 2012
__rpc_xdr is no longer available on FreeBSD 10.
(XDR is typedef'd as "struct XDR" and not "struct __rpc_xdr").
By the way, why did we ever need this? Probably
it should be removed. Leaving for __OpenBSD__ for now.
Fixes the following warning:
In file included from ../../../imports/x11/include/X11/Xutil.h:54,
from ../../../imports/x11/include/X11/Intrinsic.h:54,
from Action.c:64:
../../../imports/x11/include/X11/keysym.h:49:1: warning: "XK_MISCELLANY" redefined
<command-line>: warning: this is the location of the previous definition
<keysym.h> which includes all key symbols and loads <keysymdef.h>
is automaticlly included by the X Toolkit.
This patch removes #include <keysymdef.h> whenever not needed,
and adds #define XK_MISCALLANY in the source code where required.
Add missing prototypes and header files to the dtfile
code in order to move closer towards 64-bit compatibility.
Extract the following functions from Motif internal headers:
_XmGetWidgetExtData
_XmRecordEvent
_XmStringUngenerate
_XmTextFieldSetDestination
_XmGetActiveTopLevelMenu
Extract manually prototypes of the obsolete Motif interface:
_XmHighlightBorder
_XmUnhighlightBorder
Remove XmPrivate.h if extractprototype.awk fails
Make the following header files available via -I:
codelibs/boolean.h
codelibs/pathutils.h
codelibs/shellutils.h
and remove shellutils.h from dtwm directory.
According to the spec, blank lines in message catalogs or lines
beginning with '$ ' are valid comments.
However, there were many cases where lines in the message catalogs
contained just a single '$', without the required space after it.
Under linux, this caused 126766 error lines (in my builds) of the
form:
... unknown directive `': line ignored
This also causes gencat to exit with a non-0 exit code. Even though
gencat says it ignores the line, it really doesn't.
An early porting change to programs/localized/util/merge.c was made to
ignore this return value on linux. This hack has now been removed.
Build logs are a lot smaller and cleaner now.
- Add missing includes and prototypes
- Improve type compatibility
- Use <Xm/XmPrivate.h> for unofficial libXm headers
With this patch, dtpad no longer crashes on startup
on FreeBSD/amd64 because of a truncated 64-bit pointer.
This code tried to automatically generate the X DISPLAY
from the combination of the hostname and display number;
however 127.0.0.1:0 is normally rejected by X11, so this
technique is no good. Fixes dticon hang on startup, caused by
XOpenDisplay failure leading to this message from tttrace:
tt_default_session_set(0x0x875190=="X 127.0.0.1 0") = 1032 (TT_ERR_ACCESS)
- Const strings referenced by non-const variables.
- Incorrect format specifers for printing addresses
- Unused variables
- Signed comparison to unsigned
Also fix an incorrect enumeration value in a switch statement.
Fixes:
agent.c: In function '_DtCm_init_agent':
agent.c:160: warning: passing argument 5 of 'registerrpc' from incompatible pointer type
agent.c:160: warning: passing argument 6 of 'registerrpc' from incompatible pointer type
agent.c:167: warning: passing argument 5 of 'registerrpc' from incompatible pointer type
agent.c:167: warning: passing argument 6 of 'registerrpc' from incompatible pointer type
A patch from Pascal Stumpf using external jpeg broke linux builds,
since libjpeg needs to be linked in when using a remote jpeg lib.
So, in lnxLib.tmpl, define SharedDtHelpReqs so -ljpeg is used. Also,
in DtHelp/Imakefile, use proper Arch defines so external jpeg libs are
only used on linux, fbsd, and obsd systems.
This is a non-POSIX/ISO-C header. It is ok to include this on Linux, but it
is obsolete on BSD; FreeBSD even throws an error if you include it with
__STDC__ defined. Every system should nowadays have malloc() defined in
stdlib.h.
Diff is largely mechanical, replacing malloc.h with stdlib.h where it is not
yet included anyway.
Nowadays, OpenMotif is itself linked to libjpeg, so pulling in another
version of it causes symbol size mismatches, not to mention the maintenance
burden and security implications arising from keeping our own copy of libjpeg.
We still need some of the header files provided here because they are internal
to libjpeg and not installed on most distributions.
In part of the tooltalk rpc code (mp_message.c), it was assumed that on
the majority of platforms, sizeof(uid_t)=sizeof(gid_t)=sizeof(long). On
Linux-x64, uid_t is an unsigned int, which makes the code fail: all
tooltalk messages fail to send with an RPC_CANTENCODEARGS at the
rpc-level, and TT_INTERNAL_ERR for the actual program. We instead
change the code to explicitly examine sizeof(uid_t) to see whether it is
int or long sized. This allows tooltalk-dependent functinoality
like logout and multiple calls to dtfile to work.
Enums may be represented with a smaller type than int; however, they are
automatically promoted to int when passed in va_arg lists, just as
short, char, etc. are. GCC thus "knows" that you never want to call
va_arg with an enum type, and instead inserts an abort.
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 Douglas Mencken <dougmencken@gmail.com>:
"%wc" is Microsoft extension, not supported in every Std C Library. So
if we don't want to print "%wc%wc%wc%wc%..." instead of real chars, we
shall not use it.
Before:
%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wcession[28326]:
_Tt_s_session::s_init(): 1051 (TT_ERR_INTERNAL)!
%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wcession[28326]: waitpid():
No child processes
%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wc%wcession[28326]: child
ttsession exited with status 1
After:
/usr/dt/bin/ttsession[12397]: _Tt_s_session::s_init(): 1051 (TT_ERR_INTERNAL)!
/usr/dt/bin/ttsession[12397]: waitpid(): No child processes
/usr/dt/bin/ttsession[12397]: child ttsession exited with status 1
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.
With Aaron's fixes to dtdbcache fixing a potential coredump, the
comment block in the write_db() function regarding tmpnam() no longer
applies, and the tmpnam_buf variable is no longer used.
So, remove them :)
Added proper SharedDtSvcReqs in lnxLib.tmpl and CplusplusLibC in
linux.cf. This allows the libstdc++ dependancy to be properly
declared for libDtSvc so that it is not neccessary to hardcode 'CCLINK
= g++' in the Imakefiles of programs linking angainst libDtSvc.
- by default, do not build any other locale than C for now
- do not try to build the guides. These require functioning
dtinfo/docbook
- add a Linux.lcx locale translation db. Not used yet.
- fix some overflows in dtdocbook/instant
Remove from individual Imakefiles.
Also, remove '#if 0' block in linux.cf, and remove empty
LinuxMachineDefines. This should be working correctly. If not, let me
know.
Jon Trulson