The first Windows (1.0) in existence had no NULL pointer protection at all. Real mode Windows up to 3.0 neither.
All mainstream i386 Windows versions (not x64) allow DOS programs to access the zero page in NTVDM. Thus, if a NULL pointer vulnerability were found in Windows it would be sufficient to write a DOS program to exploit (that is, if Windows does not use segmentation to separate user from kernel space, I don't know about that).
1) OpenDOS was licensed using something entirely incompatible with the GPL.
2) Yes, he (Udo Kuhnt) modified the source code, but was bound by the Caldera license. See also the opinion of Pat Villani, the original FreeDOS kernel developer here It is not possible to relicense something GPL-incompatible as GPL without permission of all copyright holders.
3) Yes
4) Yes, and they are able to do so (snatching) because their license allows them to do so. "stolen", as used on the freedos site is not the right word to use IMHO, because Udo Kuhnt could read in the OpenDOS license that this was possible.
5) This is about two utilities only (only these and not the kernel are GPL), and well it looks like DRDOS Inc has done something about it here: "Portions are licensed under GPL (SYS v2.6 and FDXXMS v.92) or other licenses."
This problem has nothing to do with binary vs. source. In fact most applications will continue
to work if you upgrade your glibc, though the other way around is trickier. Just link the app versus the lowest glibc version you want (possibly trading some
new APIs).
What we're having here are
fundamental (source+binary) changes such as NPTL support (introduced in RH 9)
source breakage -- successive glibc versions are stricter about the functions they supply when you #include .
at least that's my experience with dosemu, it can't be very different with wine from what i read (both these two programs use a lot of OS specific features). It's not only glibc by the way, also a new gcc with a less forgiving optimizer that also removes extensions (lvalue casts, multiline string literals), flex, bison and so on.
Not that all these changes are bad, but I understood that especially NPTL has been quite a biggie for wine.
For one thing the Linux world tends to break backwards compatibility towards less-than-standard programs easier than Windows and DOS before that, where lots of programs use undocumented features and lots of people would complain if they stopped working. But for Linux after all the source is often available, so one can simply say "f*ck it" to those who use undocumented interfaces.
Re:Why would someone use Watcom rather than GCC?
on
Open Watcom 1.2 Released
·
· Score: 5, Informative
Compared to current gcc's it's * a very fast compiler (compile-time speed) * that produces very compact code (in terms of size) * so the generated code *may* even be faster than gcc's (if a loop just fits in the cache), despite the fact that gcc has quite a few more years of optimization improvements now. * it also feels more native on non-UNIX platforms
(whatever that means... gcc on Windows has a ported feel, some people don't like that, some others don't mind or like it) * can generate 16-bit code, useful for bootloaders (and FreeDOS:) * even supports "far" (48-bit) pointers in protected mode * all in all very good for embedded and driver work IMHO
on the other hand GCC is much better now in terms of standard compliance (in particularly C++); OW is slowly catching up a bit, has a more extensive warning system, supports SSE(2), custom Athlon and p4 optimizations, profile guided optimization, supports many other CPUs, etc etc.
OpenWatcom is there for Linux too, you just need to compile it from source code.
It's already 100% functional as a cross-compiler (from Linux too DOS/Windows/OS/2 but still not there yet as a native compiler: it has to use it's own libc and cannot output ELF objects (only ELF executables). The debugger works too, but symbolic debugging only works with OW compiled executables.
That means it's fine for statically linked plain ANSI C executables on Linux but does not integrate very well with the GNU toolchain, X libraries,....
Strip your cookies file to the minimum:
# Netscape HTTP Cookie File
# http://www.netscape.com/newsref/std/cookie_spec.ht ml
# This is a generated file! Do not edit.
and then write protect it.
chmod gou-w ~/.netscape/cookies
add the following to/etc/hosts:
127.0.0.2 ad.doubleclick.net www.valueclick.com netadsrv.iworld.com
Well, I had to get used to FORTRAN77 "legacy" code two years ago (that was 7 years after I learned Pascal and C). I know I wasn't the only one who spent ages on finding a very strange bug...
The formula extended beyond the 72nd character!
See also this for good FORTRAN programming style.
ALWAYS USE CAPITALS IT LOOKS WAY BETTER THIS WAY;-)
The following in ~/.emacs made emacs nicer for me (I was a bit used to the Borland Pascal 7 IDE):
Basically the keys on the bottom-left corner of the keyboard don't change. A hard-core emacs user only uses these anyway;-).
However, shift+arrow-keys select, home,end,del "work" as expected. shift+del, shift+ins, ctrl+ins: cut/paste/copy. ctrl+arrows move words, etc.
It's also nice to have the "windows" key between Ctrl and Alt as "Meta" key. Debian is like that out of the box if you specify that you have a 105-key keyboard to X; other distro's might do it differently.
(pc-selection-mode) (display-time) (global-font-lock-mode) (setq kill-whole-line t view-scroll-auto-exit nil scroll-step 1 lazy-lock-defer-on-the-fly nil pc-select-meta-moves-sexps t pc-select-override-scroll-error t column-number-mode t frame-background-mode 'light visible-bell t display-time-24hr-format t display-time-day-and-date t scroll-preserve-screen-position t) (custom-set-variables '(scroll-bar-mode 'right))
In my department the standard config is: dual 166 Mhz SPARC server(solaris)+WinNT boxes, which can run exceed to access the server However, since my research is all with Unix-based programs, and the WinNT box I used is a PII-400, I was very glad I was allowed to install Linux on it, and see quite a speed improvement;-)
When I did my master's thesis, I did some very extensive calculations using Mathematica _without_ X windows running. I used "math" with an input script to do an overnight job and killed most other processes. I found this saving of memory a great advantage of Linux w.r.t. Windows, where this would be totally impossible.
I didn't really get how it's supposed to do 64-bits processing. If it's like the 80386, they have to define 64 bit segments plus prefixes (some unused instruction, like 0Fh F0h) to get a 32 bit instruction in a 64 bit segment or the other way around. And add a virtual 80386 mode:-) Or do they want to literally extend IA32? Then the first byte of the 64 bit instructions has to be F0h, for the second one there aren't many choices left, so this gets you very long binary instructions:-(
Slashdot Mirror
The first Windows (1.0) in existence had no NULL pointer protection at all. Real mode Windows up to 3.0 neither.
All mainstream i386 Windows versions (not x64) allow DOS programs to access the zero page in NTVDM. Thus, if a NULL pointer vulnerability were found in Windows it would be sufficient to write a DOS program to exploit (that is, if Windows does not use segmentation to separate user from kernel space, I don't know about that).
1) OpenDOS was licensed using something entirely incompatible with the GPL.
2) Yes, he (Udo Kuhnt) modified the source code, but was bound by the Caldera license. See also the opinion of Pat Villani, the original FreeDOS kernel developer
here
It is not possible to relicense something GPL-incompatible as GPL without permission of all copyright holders.
3) Yes
4) Yes, and they are able to do so (snatching) because their license allows them to do so. "stolen", as used on the freedos site is not the right word to use IMHO, because Udo Kuhnt could read in the OpenDOS license that this was possible.
5) This is about two utilities only (only these and not the kernel are GPL), and well it looks like DRDOS Inc has done something about it here: "Portions are licensed under GPL (SYS v2.6 and FDXXMS v.92) or other licenses."
This problem has nothing to do with binary vs. source. In fact most applications will continue to work if you upgrade your glibc, though the other way around is trickier. Just link the app versus the lowest glibc version you want (possibly trading some new APIs).
What we're having here areat least that's my experience with dosemu, it can't be very different with wine from what i read (both these two programs use a lot of OS specific features). It's not only glibc by the way, also a new gcc with a less forgiving optimizer that also removes extensions (lvalue casts, multiline string literals), flex, bison and so on.
Not that all these changes are bad, but I understood that especially NPTL has been quite a biggie for wine.
For one thing the Linux world tends to break backwards compatibility towards less-than-standard programs easier than Windows and DOS before that, where lots of programs use undocumented features and lots of people would complain if they stopped working. But for Linux after all the source is often available, so one can simply say "f*ck it" to those who use undocumented interfaces.
Compared to current gcc's it's ... gcc on Windows has a ported feel, some people don't like that, some others don't mind or like it) :)
* a very fast compiler (compile-time speed)
* that produces very compact code (in terms of size)
* so the generated code *may* even be faster than gcc's (if a loop just fits in the cache), despite the fact that gcc has quite a few more years of optimization improvements now.
* it also feels more native on non-UNIX platforms
(whatever that means
* can generate 16-bit code, useful for bootloaders (and FreeDOS
* even supports "far" (48-bit) pointers in protected mode
* all in all very good for embedded and driver work IMHO
on the other hand GCC is much better now in terms of standard compliance (in particularly C++); OW is slowly catching up a bit, has a more extensive warning system, supports SSE(2), custom Athlon and p4 optimizations, profile guided optimization, supports many other CPUs,
etc etc.
OpenWatcom is there for Linux too, you just need to compile it from source code.
....
It's already 100% functional as a cross-compiler
(from Linux too DOS/Windows/OS/2 but still not there yet as a native compiler: it has to use it's own libc and cannot output ELF objects (only ELF executables). The debugger works too, but
symbolic debugging only works with OW compiled
executables.
That means it's fine for statically linked plain ANSI C executables on Linux but does not integrate very well with the GNU toolchain, X libraries,
Anyone still using write and talk?
NAME
write - send a message to another user
SYNOPSIS
write user [ttyname]
DESCRIPTION
Write allows you to communicate with other users, by copying lines from
your terminal to theirs.
and another goodie:
NAME
talk - talk to another user
SYNOPSIS
talk person [ttyname]
DESCRIPTION
Talk is a visual communication program which copies lines from your ter
minal to that of another user.
Strip your cookies file to the minimum:t ml
/etc/hosts:
# Netscape HTTP Cookie File
# http://www.netscape.com/newsref/std/cookie_spec.h
# This is a generated file! Do not edit.
and then write protect it.
chmod gou-w ~/.netscape/cookies
add the following to
127.0.0.2 ad.doubleclick.net www.valueclick.com netadsrv.iworld.com
Well, I had to get used to FORTRAN77 "legacy" code two years ago (that was 7 years after I learned Pascal and C). I know I wasn't the only one who spent ages on finding a very strange bug...
The formula extended beyond the 72nd character!
See also this for good FORTRAN programming style. ALWAYS USE CAPITALS IT LOOKS WAY BETTER THIS WAY;-)
You could check out X Northern Captain, see www.xnc.dubna.su.
The following in ~/.emacs made emacs nicer for me (I was a bit used to the Borland Pascal 7 IDE):
;-).
Basically the keys on the bottom-left corner of the keyboard don't change. A hard-core emacs user only uses these anyway
However, shift+arrow-keys select, home,end,del "work" as expected. shift+del, shift+ins, ctrl+ins: cut/paste/copy. ctrl+arrows move words, etc.
It's also nice to have the "windows" key between Ctrl and Alt as "Meta" key. Debian is like that out of the box if you specify that you have a 105-key keyboard to X; other distro's might do it differently.
(pc-selection-mode)
(display-time)
(global-font-lock-mode)
(setq kill-whole-line t
view-scroll-auto-exit nil
scroll-step 1
lazy-lock-defer-on-the-fly nil
pc-select-meta-moves-sexps t
pc-select-override-scroll-error t
column-number-mode t
frame-background-mode 'light
visible-bell t
display-time-24hr-format t
display-time-day-and-date t
scroll-preserve-screen-position t)
(custom-set-variables
'(scroll-bar-mode 'right))
In my department the standard config is: ;-)
dual 166 Mhz SPARC server(solaris)+WinNT boxes, which can run exceed to access the server
However, since my research is all with Unix-based programs, and the WinNT box I used is a PII-400, I was very glad I was allowed to install Linux on it, and see quite a speed improvement
When I did my master's thesis, I did some very extensive calculations using Mathematica _without_ X windows running.
I used "math" with an input script to do an overnight job and killed most other processes. I found this saving of memory a great advantage of Linux w.r.t. Windows, where this would be totally impossible.
I didn't really get how it's supposed to do 64-bits processing. :-) :-(
If it's like the 80386, they have to define 64 bit segments plus prefixes (some unused instruction, like 0Fh F0h) to get a 32 bit instruction in a 64 bit segment or the other way around.
And add a virtual 80386 mode
Or do they want to literally extend IA32? Then the first byte of the 64 bit instructions has to be F0h, for the second one there aren't many choices left, so this gets you very long binary instructions