From Newsgroup: comp.os.linux.advocacy

On Tue, 2 Dec 2025 20:13:15 -0000 (UTC)
Gremlin <nobody@haph.org> wrote:

Interesting - I'm curious how common that actually was back in the
day, though? I don't recall a lot of DOS applications that I used
chaining from one EXE to another, unless you were really into
launcher-menu type utilities; most of what I remember was single
EXEs for the main program plus accessory EXEs for configuration
(i.e. the inevitable SOUNDSET.EXE and its ilk,) and transfer of
control was usually mediated by a *.BAT launcher script.

It was common enough to be known amongst every coder I knew. Some programmers too. Take some of the multi floppy install packages for
example. Some decrypted the necessary materials as they built the
primary file on your computer. The primary file wouldn't always have
a proper executable extension, but, it was still actually an .EXE
most of the time.

Huh, I'm trying to model what an exploit would look like here - who &
what would be vulnerable to this? Obviously you *can* create a disk
file with a non-EXE extension & whatever contents you want, but under
what circumstances is another program gonna call the load-and-execute
routine on any arbitrary filename (other than, as mentioned, app-menu
utilities or command-shell alternatives?) Or if the game is to replace
one of an application suite's own I-can't-believe-it's-not-EXEs with a
Trojan, which developers bothered to mask their secondary EXEs under a different extension, and why...?

(I mean, yes, installers might well build a final EXE from smaller
and/or compressed/encrypted chunks, but the *resulting* file would
normally still have an EXE extension, and be invoked the usual way.)

Not saying that it doesn't make sense to check files on a better-safe- than-sorry heuristic, just trying to figure out how you'd get to the
point of pulling that kind of trick in the first place...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 2025-12-03 17:39, John Ames wrote:

On Tue, 2 Dec 2025 20:13:15 -0000 (UTC)
Gremlin <nobody@haph.org> wrote:

Interesting - I'm curious how common that actually was back in the
day, though? I don't recall a lot of DOS applications that I used
chaining from one EXE to another, unless you were really into
launcher-menu type utilities; most of what I remember was single
EXEs for the main program plus accessory EXEs for configuration
(i.e. the inevitable SOUNDSET.EXE and its ilk,) and transfer of
control was usually mediated by a *.BAT launcher script.

It was common enough to be known amongst every coder I knew. Some
programmers too. Take some of the multi floppy install packages for
example. Some decrypted the necessary materials as they built the
primary file on your computer. The primary file wouldn't always have
a proper executable extension, but, it was still actually an .EXE
most of the time.

Huh, I'm trying to model what an exploit would look like here - who &
what would be vulnerable to this? Obviously you *can* create a disk
file with a non-EXE extension & whatever contents you want, but under
what circumstances is another program gonna call the load-and-execute
routine on any arbitrary filename (other than, as mentioned, app-menu utilities or command-shell alternatives?) Or if the game is to replace
one of an application suite's own I-can't-believe-it's-not-EXEs with a Trojan, which developers bothered to mask their secondary EXEs under a different extension, and why...?

(I mean, yes, installers might well build a final EXE from smaller
and/or compressed/encrypted chunks, but the *resulting* file would
normally still have an EXE extension, and be invoked the usual way.)

Not saying that it doesn't make sense to check files on a better-safe- than-sorry heuristic, just trying to figure out how you'd get to the
point of pulling that kind of trick in the first place...

With mail software, it was common enough to try:

beautiful postcard.jpg..................exe

but this was a different trick. The other type I have not seen it.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

John Ames <commodorejohn@gmail.com> news:20251203083900.00002c04@gmail.com Wed, 03 Dec 2025 16:39:00 GMT in comp.os.linux.advocacy, wrote:

On Tue, 2 Dec 2025 20:13:15 -0000 (UTC)
Gremlin <nobody@haph.org> wrote:
Huh, I'm trying to model what an exploit would look like here - who &
what would be vulnerable to this? Obviously you *can* create a disk
file with a non-EXE extension & whatever contents you want, but under
what circumstances is another program gonna call the load-and-execute
routine on any arbitrary filename (other than, as mentioned, app-menu utilities or command-shell alternatives?) Or if the game is to replace
one of an application suite's own I-can't-believe-it's-not-EXEs with a Trojan, which developers bothered to mask their secondary EXEs under a different extension, and why...?

I wasn't writing about trojans using this? A trojan obviously could, but,
that isn't what I was describing...

I was writing about some installers doing it. Just not using a .bat file
to pass control but doing it themselves. They'd recombine pieces of the executable (a chunk on each floppy for example) and then pass control to
the final resulting file which would be an .EXE, but not necessarily with
that file extension.

I suppose one could think of it as a very simple way to keep 'nosey'
people out? If the program comes with an install.exe and some 1,2,3 etc
files that turn into a .DAT file; you probably won't give it a second look. You assume that because it's a .DAT file that it cannot be directly
executed- that the install.exe is doing all the work. And it's using the
.DAT file for instructions/configuration/data, etc, not that the .DAT file
is the next stage of the install process itself.

As for the trojan aspect you bring up, I did once use a .DLL file as a
marker so that the program wouldn't access your email client for the 2nd
time and email anyone again. The file wasn't really a .DLL though, but you wouldn't have been the wiser if you didn't actually examine it. It had a legitimate Windows name with proper date/time stamps that would trick you
into thinking the file was as old as the rest of the common .DLLs on your machine - You wouldn't have known it was created that morning for example. Using DOS interrupts...

Here's a little code from the program I was writing about. It's primarily written in an ancient DOS based language called ASIC. v5 specifically.

rem ***Get/Set Date/Time stamps

get_fdt:
if file_handle>4 then
AX=&HEX5700
BX=FILE_HANDLE
INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA)
NEWDATE=CX
NEWTIME=DX
endif
RETURN

set_fdt:
if file_handle>4 then
AX=&HEX5701
BX=FILE_HANDLE
CX=NEWDATE
DX=NEWTIME
INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA)
endif
RETURN

And these are the interrupts to get the current attribute and null it and
then put it back later...

rem ***Attribute get/set interrupts

get_attr:
AX = &HEX4300
DX = VARPTR(Filename$)
CX = NewAttr
INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA)
return

set_attr:
AX = &HEX4301
DX = VARPTR(Filename$)
CX = NewAttr
INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA)
return

You just set newattr=0 and make the call, tada; now it's a normal file suitable for read/write.

Save it beforehand with the get attr call, save the variable, call the set routine again when you're finished phucking around with it.

Which is what this subroutine did:

pre_open:
rem *** routine when called with getem=0 will
rem obtain the current file attributes, retain this
rem and reset the attribute to null for read/write.
rem If called with getem=1 it will restore the attribute
rem to what it was previously.
if getem=0 then
gosub get_attr:
oldattr=newattr
newattr=0
gosub set_attr:
else
newattr=oldattr
gosub set_attr:
endif
return

ASICs built in file I/O routines left much to be desired speed wise, and
when you're moving 10k or more around, you want it done fast. You don't
have time to phuck around going byte by byte. Nah, you allocate some
memory and pull a chunk all at once with a single DOS interrupt call.
Super fucking quick. Plus once it's in memory, you can do whatever needs
to be done much faster than doing it with the file on disk. RAM is faster after all. then set the file pointer, dump the ram content right back -
again super fucking quick. I was trying to explain this previously but it somehow got lost in translation I suppose.

You'll have to ignore the comments, the 'engine' is c/p from a particular piece of self replicating code I wrote decades ago.

rem open_file chart!
rem ax=&hex3d00
rem read-only
rem ax=&hex3d01
rem write only
rem ax=&hex3d02
rem read/write

open_file:
rem See chart for access mode used.
AX=&HEX3D02
DX = VARPTR(Filename$)
INT86(&HEX21,AX,NA,na,DX,NA,NA,NA,NA,NA)
file_handle=ax
return

write_file:
rem this routine will write selected bytes at whatever current position
rem from whatever buffer i choose into the file.
rem if the routine did not write all data ax will not equal cx upon
rem return from int call.
rem define dx register before calling this routine to point to the
rem memory address of the buffer area you want to write from. like so:
rem dx=varptr(buffer(0))
rem cx is how many bytes to write :)
if file_handle>4 then
ax=&hex4000
bx=file_handle
cx=bytesize
int86(&hex21,ax,bx,cx,dx,na,na,na,na,na)
byteswritten=ax
endif
return

read_file:
rem as the name implies, it reads bytes into a buffer. :-)
rem as with write_file, you need to predefine the dx register for the
rem buffer where you want the info stored. Like so: dx=varptr(buffer(0))
rem if you don't, this routine will not work, or will overwrite some
rem other section of memory. And for virus coding, this is very bad! :)
rem cx register is how many bytes to read :)
if file_handle>4 then
ax=&hex3f00
bx=file_handle
cx=bytesize
int86(&hex21,ax,bx,cx,dx,na,na,na,na,na)
bytesread=ax
endif
return

close_file:
rem Close the file handle. If the file handle is less then 4, then
rem this routine will simply exit.
if file_handle>4 then
ax=&hex3e00
bx=file_handle
int86(&hex21,ax,bx,na,na,na,na,na,na,na)
endif
return

Why muck around with byte for byte reads and writes when you can have the
OS give you much bigger chunks at once right? It's assembler speed without actually doing it in asm. It's not slow. Which is why I said previously
that you could save considerable time by doing a quick looksee at the file before you opted to scan the entire damn thing.

The only limit to how many bytes that could be read/written in one go was
the size of your allocated memory. Using straight up interrupt calls, just like you would have in pure assembly is going to be faster than whatever
file i/o functions your HLL language of choice had available to you. Your completely bypassing the fluff. The drawback is that you are entirely on
your own if you go this route. You could for example, screwup and ask to
read more bytes than you allocated memory for. If you do this, you will overwrite some other region of memory with the extra bytes. which usually leads to a crash scenario. But, if you're creative and understand how your executable is built, you can take advantage of that and instead of a crash cause code execution instead - those extra bytes are executable machine
code that you intended to load this way. That's a sneaky, but very old,
method of getting around hueristics that might check to see what you're
doing. They assume it's a standard interrupt call to read bytes, not considering that you're also using it to jmp to another location in memory with additional code it doesn't presently see because that special code
isn't already in your main program.

Not saying that it doesn't make sense to check files on a better-safe- than-sorry heuristic, just trying to figure out how you'd get to the
point of pulling that kind of trick in the first place...

It's not really a trick though. It was just using a DOS interrupt as
intended. As I wrote initially, file extensions really don't tell you what
the file actually is. They never did.
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote <XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>:

John Ames <commodorejohn@gmail.com> news:20251203083900.00002c04@gmail.com Wed, 03 Dec 2025 16:39:00 GMT in comp.os.linux.advocacy, wrote:

On Tue, 2 Dec 2025 20:13:15 -0000 (UTC)
Gremlin <nobody@haph.org> wrote:
Huh, I'm trying to model what an exploit would look like here - who &
what would be vulnerable to this? Obviously you *can* create a disk
file with a non-EXE extension & whatever contents you want, but under
what circumstances is another program gonna call the load-and-execute
routine on any arbitrary filename (other than, as mentioned, app-menu
utilities or command-shell alternatives?) Or if the game is to replace
one of an application suite's own I-can't-believe-it's-not-EXEs with a
Trojan, which developers bothered to mask their secondary EXEs under a
different extension, and why...?

I wasn't writing about trojans using this? A trojan obviously could, but, that isn't what I was describing...

I was writing about some installers doing it. Just not using a .bat file
to pass control but doing it themselves. They'd recombine pieces of the executable (a chunk on each floppy for example) and then pass control to
the final resulting file which would be an .EXE, but not necessarily with that file extension.

I suppose one could think of it as a very simple way to keep 'nosey'
people out? If the program comes with an install.exe and some 1,2,3 etc
files that turn into a .DAT file; you probably won't give it a second look. You assume that because it's a .DAT file that it cannot be directly
executed- that the install.exe is doing all the work. And it's using the
.DAT file for instructions/configuration/data, etc, not that the .DAT file
is the next stage of the install process itself.

As for the trojan aspect you bring up, I did once use a .DLL file as a
marker so that the program wouldn't access your email client for the 2nd
time and email anyone again. The file wasn't really a .DLL though, but you wouldn't have been the wiser if you didn't actually examine it. It had a legitimate Windows name with proper date/time stamps that would trick you into thinking the file was as old as the rest of the common .DLLs on your machine - You wouldn't have known it was created that morning for example. Using DOS interrupts...

Here's a little code from the program I was writing about. It's primarily written in an ancient DOS based language called ASIC. v5 specifically.

rem ***Get/Set Date/Time stamps

get_fdt:
if file_handle>4 then
AX=&HEX5700
BX=FILE_HANDLE
INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA)
NEWDATE=CX
NEWTIME=DX
endif
RETURN

set_fdt:
if file_handle>4 then
AX=&HEX5701
BX=FILE_HANDLE
CX=NEWDATE
DX=NEWTIME
INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA)
endif
RETURN

And these are the interrupts to get the current attribute and null it and then put it back later...

rem ***Attribute get/set interrupts

get_attr:
AX = &HEX4300
DX = VARPTR(Filename$)
CX = NewAttr
INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA)
return

set_attr:
AX = &HEX4301
DX = VARPTR(Filename$)
CX = NewAttr
INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA)
return

You just set newattr=0 and make the call, tada; now it's a normal file suitable for read/write.

Save it beforehand with the get attr call, save the variable, call the set routine again when you're finished phucking around with it.

Which is what this subroutine did:

pre_open:
rem *** routine when called with getem=0 will
rem obtain the current file attributes, retain this
rem and reset the attribute to null for read/write.
rem If called with getem=1 it will restore the attribute
rem to what it was previously.
if getem=0 then
gosub get_attr:
oldattr=newattr
newattr=0
gosub set_attr:
else
newattr=oldattr
gosub set_attr:
endif
return

ASICs built in file I/O routines left much to be desired speed wise, and
when you're moving 10k or more around, you want it done fast. You don't
have time to phuck around going byte by byte. Nah, you allocate some
memory and pull a chunk all at once with a single DOS interrupt call.
Super fucking quick. Plus once it's in memory, you can do whatever needs
to be done much faster than doing it with the file on disk. RAM is faster after all. then set the file pointer, dump the ram content right back -
again super fucking quick. I was trying to explain this previously but it somehow got lost in translation I suppose.

You'll have to ignore the comments, the 'engine' is c/p from a particular piece of self replicating code I wrote decades ago.

rem open_file chart!
rem ax=&hex3d00
rem read-only
rem ax=&hex3d01
rem write only
rem ax=&hex3d02
rem read/write

open_file:
rem See chart for access mode used.
AX=&HEX3D02
DX = VARPTR(Filename$)
INT86(&HEX21,AX,NA,na,DX,NA,NA,NA,NA,NA)
file_handle=ax
return

write_file:
rem this routine will write selected bytes at whatever current position
rem from whatever buffer i choose into the file.
rem if the routine did not write all data ax will not equal cx upon
rem return from int call.
rem define dx register before calling this routine to point to the
rem memory address of the buffer area you want to write from. like so:
rem dx=varptr(buffer(0))
rem cx is how many bytes to write :)
if file_handle>4 then
ax=&hex4000
bx=file_handle
cx=bytesize
int86(&hex21,ax,bx,cx,dx,na,na,na,na,na)
byteswritten=ax
endif
return

read_file:
rem as the name implies, it reads bytes into a buffer. :-)
rem as with write_file, you need to predefine the dx register for the
rem buffer where you want the info stored. Like so: dx=varptr(buffer(0))
rem if you don't, this routine will not work, or will overwrite some
rem other section of memory. And for virus coding, this is very bad! :)
rem cx register is how many bytes to read :)
if file_handle>4 then
ax=&hex3f00
bx=file_handle
cx=bytesize
int86(&hex21,ax,bx,cx,dx,na,na,na,na,na)
bytesread=ax
endif
return

close_file:
rem Close the file handle. If the file handle is less then 4, then
rem this routine will simply exit.
if file_handle>4 then
ax=&hex3e00
bx=file_handle
int86(&hex21,ax,bx,na,na,na,na,na,na,na)
endif
return

Why muck around with byte for byte reads and writes when you can have the
OS give you much bigger chunks at once right? It's assembler speed without actually doing it in asm. It's not slow. Which is why I said previously
that you could save considerable time by doing a quick looksee at the file before you opted to scan the entire damn thing.

The only limit to how many bytes that could be read/written in one go was
the size of your allocated memory. Using straight up interrupt calls, just like you would have in pure assembly is going to be faster than whatever
file i/o functions your HLL language of choice had available to you. Your completely bypassing the fluff. The drawback is that you are entirely on
your own if you go this route. You could for example, screwup and ask to
read more bytes than you allocated memory for. If you do this, you will overwrite some other region of memory with the extra bytes. which usually leads to a crash scenario. But, if you're creative and understand how your executable is built, you can take advantage of that and instead of a crash cause code execution instead - those extra bytes are executable machine
code that you intended to load this way. That's a sneaky, but very old, method of getting around hueristics that might check to see what you're doing. They assume it's a standard interrupt call to read bytes, not considering that you're also using it to jmp to another location in memory with additional code it doesn't presently see because that special code
isn't already in your main program.

Not saying that it doesn't make sense to check files on a better-safe-
than-sorry heuristic, just trying to figure out how you'd get to the
point of pulling that kind of trick in the first place...

It's not really a trick though. It was just using a DOS interrupt as intended. As I wrote initially, file extensions really don't tell you what the file actually is. They never did.

Most of what you're describing is technically possible under DOS, but the way you're framing it doesn’t match how real software of the era operated.

Yes, DOS will EXEC a file regardless of extension if the caller specifies it. No, DOS installers were not commonly stitching together disguised EXE chunks under .DAT files. That's an edge case at best.

Your interrupt calls seem legit, but "reading past a buffer to trigger execution" is more movie-hacker than real-world practice; DOS viruses mostly used explicit jumps, not accidental overreads.

Extensions mattered to the command shell even if EXEC didn't care. Saying "extensions never meant anything" is just flat wrong.

So your technical notes are mostly fine, but the narrative around them is the usual Gremlin embellishment —- stretching niche behavior into something widespread or sophisticated.
--
It's impossible for someone who is at war with themselves to be at peace with you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Wed, 3 Dec 2025 22:03:12 -0000 (UTC)
Gremlin <nobody@haph.org> wrote:

I wasn't writing about trojans using this? A trojan obviously could,
but, that isn't what I was describing...

Ah - perhaps I had a context lapse since this initially came up in a
discussion on virus scanning.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

Brock McNuggets <brock.mcnuggets@gmail.com> news:6930bb75$7$26$882e4bbb@reader.netnews.com Wed, 03 Dec 2025 22:36:37
GMT in comp.os.linux.advocacy, wrote:

On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote <XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>:
Most of what you're describing is technically possible under DOS, but
the way you're framing it doesn’t match how real software of the era operated.

All of what I described (buffer overrun specifically) works under DOS, os/2warp, Windows, Linux and MacOS. And it doesn't match software you personally are aware of is what you should have written, if your intention
was to have an actual honest discussion concerning this. We both know
that's not your intention with your reply though. You are an end user. I
am a coder. There is a huge difference between the two.

ChatGPT and the like can only help you get by to a point, Snit. It's not
going to be able to let you completely fake a technical discussion
concerning low level code with me though. Anymore so than it was useful
helping you and David Brooks gain entry into that encrypted .zip file.

Yes, DOS will EXEC a file regardless of extension if the caller
specifies it. No, DOS installers were not commonly stitching together disguised EXE chunks under .DAT files. That's an edge case at best.

I was using the .DAT extension as an example. It's not an edge case,
either. I'm familiar with several packages from back in the day that used
that 'trick' (which is not a trick of any kind). Some authors didn't want
you snooping around too much with their programs, and little 'tricks' like
that kept end users like you far away.

You probably aren't familiar with the internals of how zip2exe actually
worked, or the difference between the registered copy of pkwarez exe
compressor vs the unregistered one. It was a single byte that if toggled provided you the 'protection' of the registered version. Protection in the sense that pklite wouldn't decompress a file compressed with it if you
were using the registered version, OR, if you understood how it actually
worked and used the shareware version and changed a single byte yourself.
The registered version also offered *slightly* better compression,
depending entirely on how your executable was constructed. Depending on
the language and compiler used, this could only be a few bytes though.
Hardly worth paying for. And, it wasn't worth paying for it to disable the decompress option when changing a single byte worked just fine for that purpose.

Here's the source code to one of my first cracks. One byte changed, tada, pklite won't decompress your file anymore using the -x parameter.

a$=command$
a$=ltrim$(a$)
a$=rtrim$(a$)
print"PKEX: Prevents PKLITE from expanding .EXE files!"
print" "
open "r",1,a$
if error>0 then
print"Usage: PKEX <Filename.ext>"
beep
else
a=filepos(1,29)
a$=chr$(17)
print #1,a$ NONULL
close 1
print"File cannot be expanded by PKLITE"
end
endif

That's just simple ASIC code above. I'd typically write the crack in an
HLL, but the actual work to make the damn thing was done via disassembly.
Ie: reverse engineering.

Your interrupt calls seem legit, but "reading past a buffer to trigger execution" is more movie-hacker than real-world practice; DOS viruses
mostly used explicit jumps, not accidental overreads.

Those calls are all legit. You can cross reference any of them with Ralph Browns interrupt list. You really shouldn't rely on ChatGPT or any other
AI to participate in this discussion. It's piss easy to fool them.
Especially now that I know you're using AI to participate in the first
place. I've left a great example of that in this reply. Just to drive the
point home.

byebye:
ax=&hexfa02
dx=&hex5945
bx=rofl
int86(&hex16,ax,bx,cx,dx,na,na,na,na,na)
code &hexb8,&hex02,&hexfe,&hexbe,&hex41,&hex4e,&hexbf,&hex55,&hex4e,&hexcd,&hex2f return

code should be on the same line as the &hex material. My client wordwraps at 78 characters and I can't be arsed to change it. <G>

Chatgpt can only let you fake knowledge you don't actually have upto a
point. Without the original label and my comments, ChatGPT has no idea
what that code does.

I also took the time to feed it to googles gemini. Geminis results are
more useful from a technical breakdown, but, it doesn't know what's going
on either. When I fed it the original source code without any snipping of
my comments and using the original label, They were both mostly able to
tell me what the code was doing.

These AIs are not as reliable as you seem to think they are, bud. They
both relied on my label and my comments - neither of them were able to
properly identify what the code is doing without them. These AI things do
not actually 'think' Snit.

https://en.wikipedia.org/wiki/Buffer_overflow

If you actually comprehended what I wrote, you would have known that I was describing a buffer overflow exploit. Since you didn't have a clue,
because you don't comprehend what you read well at all (sorry bud, but
this is well documented going back decades with you) that's why you relied
on AI and shared what it told you. Which isn't correct, btw. :)

Since you assumed I was discussing viruses specifically though, I do know
of several viruses and worms from the late 80s and 90s that did use the technique. The Morris worm (which is a subset of a computer virus) was the earliest one I remember doing it. There were others, though. Just not as popular due to them either being proof of concept or having other issues
which prevented their long term survival in the wild.

There was nothing 'accidental' about those over reads. As I wrote
previously, it was intentional and required you to be very familiar with
the final executable structure of your program as it would be processed internally - not necessarily on disk. .COM files execute as is on disk in memory; what you see is what you get. .EXE files do not by default, but,
if properly crafted, they can as well.

It's *very easy* due to the nature of the files internals and executable
layout to convert a .COM into an .EXE; it only requires a small header. I actually demonstrated that little 'trick' years ago to Pooh who claimed he
was something he wasn't and like you, tried to talk out of turn.

https://en.wikipedia.org/wiki/Buffer_overflow

It would benefit you greatly to read the contents of that URL.
Specifically for *comprehension* so that you don't expose the severe lack
of actual knowledge and understanding you have on the subject of writing
low level code. You really *don't know* what the fuck you're talking about
on this subject, Snit.

Extensions mattered to the command shell even if EXEC didn't care.
Saying "extensions never meant anything" is just flat wrong.

It's not flat out wrong in the context I was explaining it, Snit.
Extensions are for end users like you who don't understand what's actually going on with the machine sitting in front of you. Specifically, how and
why it does what it does. You should never rely on a files extension to determine what that file actually is. Not if you take security seriously, anyhow. AV gives people like you a very false sense of security. You think you're safe and all is well because such and such AV scanned the file and
said it was 'ok' when it wasn't.

As I've already shown, the extension is for the end user - it really
doesn't matter to a coder/decent programmer. Neither of which you are. You cannot trust the extension. Which was the entire point of my sharing *one*
of the interrupts used to execute code.

Btw, viruses did more than just jmp around; poly/oglymorphs for example.
That's a subject well beyond your understanding though, for certain.
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

John Ames <commodorejohn@gmail.com> news:20251203144144.00004551@gmail.com Wed, 03 Dec 2025 22:41:44 GMT in comp.os.linux.advocacy, wrote:

On Wed, 3 Dec 2025 22:03:12 -0000 (UTC)
Gremlin <nobody@haph.org> wrote:

I wasn't writing about trojans using this? A trojan obviously could,
but, that isn't what I was describing...

Ah - perhaps I had a context lapse since this initially came up in a discussion on virus scanning.

Possible. It might have happened when I got specific concerning a files extension and shared simple source code that demonstrated that you can't
rely on them. Just because a file doesn't have an 'executable' extension doesn't mean the file isn't. It just means an end user probably won't be executing it directly by double clicking or typing the filename at the
command line. It doesn't mean the file isn't executable, though. I hope that clarifies things?

I also took the time, evidently wasted the time, to describe what's known as
a buffer overrun exploit as I explained the advantage of doing a quick check of the file before you opted to scan the entire thing. For some silly reason, atleast one of you assumed this would be a time consuming process; that reading a few bytes would take about as much time as reading a few more. It depends on how you go about reading it, right? If you go byte for byte,
that's time consuming and wasteful. Pull a nice chunk into a buffer using OS calls directly, it's not time consuming nor wasteful.

I enjoyed the discussion though!
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Dec 3, 2025 at 8:05:22 PM MST, "Gremlin" wrote <XnsB3AAE0B49172CHT1@cF04o3ON7k2lx05.lLC.9r5>:

Brock McNuggets <brock.mcnuggets@gmail.com> news:6930bb75$7$26$882e4bbb@reader.netnews.com Wed, 03 Dec 2025 22:36:37
GMT in comp.os.linux.advocacy, wrote:

On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote
<XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>:
Most of what you're describing is technically possible under DOS, but
the way you're framing it doesn’t match how real software of the era
operated.

All of what I described (buffer overrun specifically) works under DOS, os/2warp, Windows, Linux and MacOS.

Nobody said otherwise. Seriously, not one person ever did. Certainly not me.

Please try to read for comprehension and not just attack. It would help you a lot.

You do this often -- argue against bizarre straw men you create. And you do so out of your own hatred and personal issues. Try to do better!
--
It's impossible for someone who is at war with themselves to be at peace with you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 04/12/2025 14:24, Brock McNuggets wrote:

You do this often -- argue against bizarre straw men you create. And you do so
out of your own hatred and personal issues. Try to do better!

Clearly a Marxist.
--
Civilization exists by geological consent, subject to change without notice.
– Will Durant

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Thu, 4 Dec 2025 14:35:52 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create.
And you do so out of your own hatred and personal issues. Try to do
better!

Clearly a Marxist.

The irony here is palpable.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 04/12/2025 16:21, John Ames wrote:

On Thu, 4 Dec 2025 14:35:52 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create.
And you do so out of your own hatred and personal issues. Try to do
better!

Clearly a Marxist.

The irony here is palpable.

I'm no Marxist chum
But the guy referred to here looks like one...
--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Thu, 4 Dec 2025 18:05:17 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create.
And you do so out of your own hatred and personal issues. Try to
do better!

Clearly a Marxist.

The irony here is palpable.

I'm no Marxist chum

No, but you *do* seem to be in need of a refresher on elementary set
theory, even if we take your opinion on Marxist rhetorical tendencies
as gospel.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 04/12/2025 18:09, John Ames wrote:

On Thu, 4 Dec 2025 18:05:17 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create.
And you do so out of your own hatred and personal issues. Try to
do better!

Clearly a Marxist.

The irony here is palpable.

I'm no Marxist chum

No, but you *do* seem to be in need of a refresher on elementary set
theory, even if we take your opinion on Marxist rhetorical tendencies
as gospel.

I am afraid that one whooshed right over my head.
--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Thu, 4 Dec 2025 19:09:30 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create.
And you do so out of your own hatred and personal issues. Try to
do better!

Clearly a Marxist.

The irony here is palpable.

I'm no Marxist chum

No, but you *do* seem to be in need of a refresher on elementary set theory, even if we take your opinion on Marxist rhetorical
tendencies as gospel.

I am afraid that one whooshed right over my head.

Even if we take "members of group A exhibit property B" as a given,
that does not in itself mean that all entities exhibiting property B
are members of group A.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 04/12/2025 19:11, John Ames wrote:

On Thu, 4 Dec 2025 19:09:30 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create. >>>>>>> And you do so out of your own hatred and personal issues. Try to >>>>>>> do better!

Clearly a Marxist.

The irony here is palpable.

I'm no Marxist chum

No, but you *do* seem to be in need of a refresher on elementary set
theory, even if we take your opinion on Marxist rhetorical
tendencies as gospel.

I am afraid that one whooshed right over my head.

Even if we take "members of group A exhibit property B" as a given,
that does not in itself mean that all entities exhibiting property B
are members of group A.

In general no, in this case, almost certainly.
Almost by definition
--
“The urge to save humanity is almost always only a false face for the
urge to rule it.”
– H. L. Mencken

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

Brock McNuggets <brock.mcnuggets@gmail.com> news:6931999a$6$21$882e4bbb@reader.netnews.com Thu, 04 Dec 2025 14:24:26
GMT in comp.os.linux.advocacy, wrote:

On Dec 3, 2025 at 8:05:22 PM MST, "Gremlin" wrote <XnsB3AAE0B49172CHT1@cF04o3ON7k2lx05.lLC.9r5>:

Brock McNuggets <brock.mcnuggets@gmail.com>
news:6930bb75$7$26$882e4bbb@reader.netnews.com Wed, 03 Dec 2025
22:36:37 GMT in comp.os.linux.advocacy, wrote:

On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote
<XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>:
Most of what you're describing is technically possible under DOS, but
the way you're framing it doesn’t match how real software of the era
operated.

All of what I described (buffer overrun specifically) works under DOS,
os/2warp, Windows, Linux and MacOS.

Nobody said otherwise. Seriously, not one person ever did. Certainly not
me.

Yes, you did. You didn't understand what I was describing and misattributed
my comments to have been about viruses specifically when they weren't.

My original post:
MID: <XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>

Why muck around with byte for byte reads and writes when you can have the
OS give you much bigger chunks at once right? It's assembler speed without actually doing it in asm. It's not slow. Which is why I said previously
that you could save considerable time by doing a quick looksee at the file before you opted to scan the entire damn thing.

The only limit to how many bytes that could be read/written in one go was
the size of your allocated memory. Using straight up interrupt calls, just like you would have in pure assembly is going to be faster than whatever
file i/o functions your HLL language of choice had available to you. Your completely bypassing the fluff. The drawback is that you are entirely on
your own if you go this route. You could for example, screwup and ask to
read more bytes than you allocated memory for. If you do this, you will overwrite some other region of memory with the extra bytes. which usually leads to a crash scenario. But, if you're creative and understand how your executable is built, you can take advantage of that and instead of a crash cause code execution instead - those extra bytes are executable machine
code that you intended to load this way. That's a sneaky, but very old,
method of getting around hueristics that might check to see what you're
doing. They assume it's a standard interrupt call to read bytes, not considering that you're also using it to jmp to another location in memory with additional code it doesn't presently see because that special code
isn't already in your main program.


Snits response:
MID: <6931999a$6$21$882e4bbb@reader.netnews.com>
Your interrupt calls seem legit, but "reading past a buffer to trigger execution" is more movie-hacker than real-world practice; DOS viruses mostly used explicit jumps, not accidental overreads.

A followup by me attempting to educate Snit; that what I described is not movie-hacker but is infact real life and well known:

MID: <XnsB3AAE0B49172CHT1@cF04o3ON7k2lx05.lLC.9r5> https://en.wikipedia.org/wiki/Buffer_overflow

If you actually comprehended what I wrote, you would have known that I was describing a buffer overflow exploit. Since you didn't have a clue,
because you don't comprehend what you read well at all (sorry bud, but
this is well documented going back decades with you) that's why you relied
on AI and shared what it told you. Which isn't correct, btw. :)

Since you assumed I was discussing viruses specifically though, I do know
of several viruses and worms from the late 80s and 90s that did use the technique. The Morris worm (which is a subset of a computer virus) was the earliest one I remember doing it. There were others, though. Just not as popular due to them either being proof of concept or having other issues
which prevented their long term survival in the wild.

There was nothing 'accidental' about those over reads. As I wrote
previously, it was intentional and required you to be very familiar with
the final executable structure of your program as it would be processed internally - not necessarily on disk. .COM files execute as is on disk in memory; what you see is what you get. .EXE files do not by default, but,
if properly crafted, they can as well.

It's *very easy* due to the nature of the files internals and executable
layout to convert a .COM into an .EXE; it only requires a small header. I actually demonstrated that little 'trick' years ago to Pooh who claimed he
was something he wasn't and like you, tried to talk out of turn.

https://en.wikipedia.org/wiki/Buffer_overflow

It would benefit you greatly to read the contents of that URL.
Specifically for *comprehension* so that you don't expose the severe lack
of actual knowledge and understanding you have on the subject of writing
low level code. You really *don't know* what the fuck you're talking about
on this subject, Snit.

Please try to read for comprehension and not just attack. It would help
you a lot.

ROFL! Stop projecting, you tech illiterate shithead.

And why didn't you try using chatgpt again with this:
Those calls are all legit. You can cross reference any of them with Ralph Browns interrupt list. You really shouldn't rely on ChatGPT or any other
AI to participate in this discussion. It's piss easy to fool them.
Especially now that I know you're using AI to participate in the first
place. I've left a great example of that in this reply. Just to drive the
point home.

byebye:
ax=&hexfa02
dx=&hex5945
bx=rofl
int86(&hex16,ax,bx,cx,dx,na,na,na,na,na)
code &hexb8,&hex02,&hexfe,&hexbe,&hex41,&hex4e,&hexbf,&hex55,&hex4e,&hexcd,&hex2f
return

Chatgpt can only let you fake knowledge you don't actually have upto a
point. Without the original label and my comments, ChatGPT has no idea
what that code does.

I also took the time to feed it to googles gemini. Geminis results are
more useful from a technical breakdown, but, it doesn't know what's going
on either. When I fed it the original source code without any snipping of
my comments and using the original label, They were both mostly able to
tell me what the code was doing.

These AIs are not as reliable as you seem to think they are, bud. They
both relied on my label and my comments - neither of them were able to
properly identify what the code is doing without them. These AI things do
not actually 'think' Snit.

You think that by not including it in your reply that it goes away or something?
ROFL!!!
Chatgpt couldn't help you fake it this time, bud. Any guesses then as to what that code does? I'll share the original and you can run it thru chatgpt if you'd like. ROFLMFAO! It's real code, it actually does something, very specific.
But you are totally fucking clueless without Chatgpts help - because you know NOTHING of writing low level code. You should have stayed in your lane, fucktard.
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

John Ames <commodorejohn@gmail.com> news:20251204082129.000038cc@gmail.com Thu, 04 Dec 2025 16:21:29 GMT in comp.os.linux.advocacy, wrote:

On Thu, 4 Dec 2025 14:35:52 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create.
And you do so out of your own hatred and personal issues. Try to do
better!

Clearly a Marxist.

The irony here is palpable.

ROFL, isn't it though. Brock McNuggets is also known as Snit aka Michael Glasser the prescott computer guy. . These links should help you out:

<https://tinyurl.com/WhatIsSnit>
<https://tinyurl.com/Snitliesmethods>
<https://tinyurl.com/Snit-Reviews>
<https://tinyurl.com/Snitwhopperlie>
<https://tinyurl.com/Snit-teddybear>
<https://tinyurl.com/Snitonduck>
<https://tinyurl.com/Snitongoogle>
<https://tinyurl.com/Snitdrugabuse1>
<https://tinyurl.com/Snitdrugabuse2>
<https://tinyurl.com/Snitdrugabuse3>
<https://tinyurl.com/Snitdrugabuse4>
<https://tinyurl.com/Snitdrugabuse5>
<https://tinyurl.com/Snitdrugabuse6>
<https://tinyurl.com/Snitdrugabuse7>
<https://tinyurl.com/Snitdrugabuse8>
<https://tinyurl.com/Snitdrugabuse9>
<https://tinyurl.com/Snitdrugabuse10>
<https://tinyurl.com/Snitdrugabuse11>

--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

The Natural Philosopher <tnp@invalid.invalid>
news:10gs688$bvup$2@dont-email.me Thu, 04 Dec 2025 14:35:52 GMT in comp.os.linux.advocacy, wrote:

On 04/12/2025 14:24, Brock McNuggets wrote:

You do this often -- argue against bizarre straw men you create. And
you do so out of your own hatred and personal issues. Try to do better!

Clearly a Marxist.

ROFL! Try not to take all of the jenkem snit likes to share at once, ok?

<https://tinyurl.com/WhatIsSnit>
<https://tinyurl.com/Snitliesmethods>
<https://tinyurl.com/Snit-Reviews>
<https://tinyurl.com/Snitwhopperlie>
<https://tinyurl.com/Snit-teddybear>
<https://tinyurl.com/Snitonduck>
<https://tinyurl.com/Snitongoogle>
<https://tinyurl.com/Snitdrugabuse1>
<https://tinyurl.com/Snitdrugabuse2>
<https://tinyurl.com/Snitdrugabuse3>
<https://tinyurl.com/Snitdrugabuse4>
<https://tinyurl.com/Snitdrugabuse5>
<https://tinyurl.com/Snitdrugabuse6>
<https://tinyurl.com/Snitdrugabuse7>
<https://tinyurl.com/Snitdrugabuse8>
<https://tinyurl.com/Snitdrugabuse9>
<https://tinyurl.com/Snitdrugabuse10>
<https://tinyurl.com/Snitdrugabuse11>

He's projecting and trying *very hard* to excuse the fact he fucked up in a big way in this thread when he responded to me mostly using ChatGPT to help him because he knows fuckall about low level code of any kind. In case you
are a bit, slow, Brock McNuggets is Snit. Also known as Michael Lee Glasser
of Prescott Arizona. The presscott computer guy. ROFLMFAO! Don't be a such a tool going forward, bro! :)
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Dec 4, 2025 at 3:48:00 PM MST, "Gremlin" wrote <XnsB3ABB512155AEHT1@cF04o3ON7k2lx05.lLC.9r5>:

The Natural Philosopher <tnp@invalid.invalid> news:10gs688$bvup$2@dont-email.me Thu, 04 Dec 2025 14:35:52 GMT in comp.os.linux.advocacy, wrote:

On 04/12/2025 14:24, Brock McNuggets wrote:

You do this often -- argue against bizarre straw men you create. And
you do so out of your own hatred and personal issues. Try to do better!

Clearly a Marxist.

ROFL! Try not to take all of the jenkem snit likes to share at once, ok?

You really are in a trolling mode. LOL! Time to help you remember how clueless you are. Keep in mind I do this IN RESPONSE to your trolling lies. :)

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

* Gremlin thought Unicode letter-like symbols were a different font.

<XnsAB71E34305C94HT1@5X40MEzgnn1982sRxYGhQ1dvm7V9MV2Z64U.TM6M5Igc40qPeP.gaV5b

-----
And unlike your silly code tests you've tried to do
recently, AZ doesn't require any specific fonts, ...
-----

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

* Gremlin got confused over what degrees he says he has and what
they mean.

* You have two degrees, both in CS and you did not know IT was different.
* You have two degrees, both in IT.
* You have two degrees, one in IT and one in CS.
* You blame me for you confusing IT with IS though you offer no evidence.
* You cannot decide if you have "two" degrees or "several".
* They’re "honorary" except when you "did the work and took the tests."
* You project your confusion and dishonesty onto me.

All trivial to show:

Diesel / Gremlin <XnsAB593FA1DFBDHT1@MjEwUG.BDMbgpk>:
-----
Well, I have two Masters myself, but they are in CS I
wasn't aware CS and I.T were/are seperate entities now.
-----

Diesel / Gremlin <XnsAC703AA7A6220HT1@tkRp4lHo04W6T4lOY83W.tuvxq31.7>:
-----
Unlike yourself snit, I hold two honorary masters in IT
-----

Diesel / Gremlin <XnsAC703AA7A6220HT1@tkRp4lHo04W6T4lOY83W.tuvxq31.7>:
-----
We discussed at length previously his masters in IS, and
mine in IT and the differences between them. He was quite
adamant that he had a masters in IS, *not* IT as is mine.
-----

Diesel / Gremlin <XnsAC75C8B08FCD2HT1@dcFn0WjC2iFiA86fj2h.35Y>:
-----
One is in CS, the other is in IT.
-----

Diesel / Gremlin <XnsB31E2432CF33FHT1@cF04o3ON7k2lx05.lLC.9r5>:
-----
I have several honorary degrees,
-----

Diesel / Gremlin <XnsB31E2432CF33FHT1@cF04o3ON7k2lx05.lLC.9r5>:
-----
I actually did the work and took the tests to earn them
-----

And the most ironic accusation of yours:

Diesel / Gremlin <XnsAC703AA7A6220HT1@tkRp4lHo04W6T4lOY83W.tuvxq31.7>:
-----
I'd also like to know how Snit could be so confused
concerning which degree he has.
-----

----------------------------------------------------------------------
--
It's impossible for someone who is at war with themselves to be at peace with you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Dec 4, 2025 at 3:47:58 PM MST, "Gremlin" wrote <XnsB3ABB51108C55HT1@cF04o3ON7k2lx05.lLC.9r5>:

John Ames <commodorejohn@gmail.com> news:20251204082129.000038cc@gmail.com Thu, 04 Dec 2025 16:21:29 GMT in comp.os.linux.advocacy, wrote:

On Thu, 4 Dec 2025 14:35:52 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

You do this often -- argue against bizarre straw men you create.
And you do so out of your own hatred and personal issues. Try to do
better!

Clearly a Marxist.

The irony here is palpable.

ROFL, isn't it though.

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

* Gremlin got confused over Preference files and profiles on macOS.

<XnsACA2266D9357HT1@b61h2qa58gRz40SbioSFbq.6IDI>:
-----
Did he really tell you that after deleting your profile for the
photos program (when it's not running - I shouldn't have to make
sure you understand that, but, you are David Brooks and well, you
aren't exactly the brightest bulb in the pack.) you should restart
your machine to be sure the effect worked? David, y2k called and
they'd like their technology back if that's really the case. rofl.

Ensure no processes are running that program uses, ensure the
program itself isn't running, whack your profile. Start the
program, don't restart your machine or logoff/login again to 'fix'
it without first seeing if it's okay after whacking the profile.
-----

<XnsACA22716D09FHT1@b61h2qa58gRz40SbioSFbq.6IDI>
-----
Do you have anything you care about under that profile
that you want to retain? If you do, and this includes any
customizations you've made to the GUI then you have to
determine if it's worth retaining, or just scrapping and
starting over. Do you have any user data specifically tied
to that account that would be lost if you purged it?
-----

----------------------------------------------------------------------
--
It's impossible for someone who is at war with themselves to be at peace with you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Dec 4, 2025 at 3:47:56 PM MST, "Gremlin" wrote <XnsB3ABB50F457B1HT1@cF04o3ON7k2lx05.lLC.9r5>:

Brock McNuggets <brock.mcnuggets@gmail.com> news:6931999a$6$21$882e4bbb@reader.netnews.com Thu, 04 Dec 2025 14:24:26
GMT in comp.os.linux.advocacy, wrote:

On Dec 3, 2025 at 8:05:22 PM MST, "Gremlin" wrote
<XnsB3AAE0B49172CHT1@cF04o3ON7k2lx05.lLC.9r5>:

Brock McNuggets <brock.mcnuggets@gmail.com>
news:6930bb75$7$26$882e4bbb@reader.netnews.com Wed, 03 Dec 2025
22:36:37 GMT in comp.os.linux.advocacy, wrote:

On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote
<XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>:
Most of what you're describing is technically possible under DOS, but
the way you're framing it doesn’t match how real software of the era >>>> operated.

All of what I described (buffer overrun specifically) works under DOS,
os/2warp, Windows, Linux and MacOS.

Nobody said otherwise. Seriously, not one person ever did. Certainly not
me.

Yes, you did.

But you cannot quote it. Which means you just got confused again.

I never said, suggested, hinted, or implied what you attributed to me.

Learn to read!

...
--
It's impossible for someone who is at war with themselves to be at peace with you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

At Wed, 3 Dec 2025 22:03:12 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

read_file: rem as the name implies, it reads bytes into a buffer. :-)
rem as with write_file, you need to predefine the dx register for the
rem buffer where you want the info stored. Like so:
dx=varptr(buffer(0)) rem if you don't, this routine will not work, or
will overwrite some rem other section of memory. And for virus
coding, this is very bad! :) rem cx register is how many bytes to
read :) if file_handle>4 then ax=&hex3f00 bx=file_handle cx=bytesize int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) bytesread=ax endif return

Hey, just wanted to mention that Linux used to use int86(0x80,...)
for its own syscalls. In C, read(2) is the way to read into a buffer,
which would set up the syscall (call to interrupt 0x80). I guess in DOS,
C would set up the interrupt call similar to how you show, and then
call the interrupt.

Modern processors have an actual SYSCALL intrinsic, so no more interrupt
call to enter the kernel.

I remember DOS interrupts 0x21 (DOS itself), and 0x10(BIOS, iirc).
--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G
OS: Linux 6.18.0 D: Mint 22.2 DE: Xfce 4.18
NVIDIA: 580.105.08 Mem: 258G
"Disc space - the final frontier!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

vallor <vallor@vallor.earth> news:10h2u70$36bnl$1@dont-email.me Sun, 07 Dec 2025 04:01:36 GMT in comp.os.linux.advocacy, wrote:

At Wed, 3 Dec 2025 22:03:12 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

read_file: rem as the name implies, it reads bytes into a buffer. :-)
rem as with write_file, you need to predefine the dx register for the
rem buffer where you want the info stored. Like so:
dx=varptr(buffer(0)) rem if you don't, this routine will not work, or
will overwrite some rem other section of memory. And for virus
coding, this is very bad! :) rem cx register is how many bytes to
read :) if file_handle>4 then ax=&hex3f00 bx=file_handle cx=bytesize
int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) bytesread=ax endif return

Hey, just wanted to mention that Linux used to use int86(0x80,...)
for its own syscalls. In C, read(2) is the way to read into a buffer,
which would set up the syscall (call to interrupt 0x80). I guess in DOS,
C would set up the interrupt call similar to how you show, and then
call the interrupt.

I remember from writing elf binaries. <G> Fun and educational times.

Modern processors have an actual SYSCALL intrinsic, so no more interrupt
call to enter the kernel.

Windows API calls can still be used to enter the kernel. Modern CPUs
running a flavor of DOS still respect DOS interrupt calls when running in 'real mode' kernel entrance. It's known as 'real mode' vs 'Protected mode
and virtualization'

As for Linux, here's a c/p from google AI:

Yes, Linux absolutely uses interrupts and interrupt calls
(like the syscall instruction on modern CPUs) to allow user-space
processes to request kernel services, enabling privileged kernel access
for tasks like file I/O or process management, with specific mechanisms
like IRQs for hardware, `syscall` for system calls, and exceptions for
errors all transitioning the CPU to kernel mode (Ring 0) to execute
privileged code. Modern systems use efficient instructions like syscall
for system calls, but the core principle of interrupt-driven transitions
to kernel space for privileged operations remains fundamental.
***

The 286 was the first to offer protected mode access. It was significantly improved with the 386. Modern CPUs still offer real mode as well. So, I'm
not sure what you mean exactly by a modern CPU in this instance? Or what
you mean by no more interrupt call to enter the kernel?

I remember DOS interrupts 0x21 (DOS itself), and 0x10(BIOS, iirc).

<G> It takes me back man.
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

At Mon, 8 Dec 2025 02:32:39 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

vallor <vallor@vallor.earth> news:10h2u70$36bnl$1@dont-email.me Sun,
07 Dec 2025 04:01:36 GMT in comp.os.linux.advocacy, wrote:

At Wed, 3 Dec 2025 22:03:12 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

read_file: rem as the name implies, it reads bytes into a buffer.
:-) rem as with write_file, you need to predefine the dx register
for the rem buffer where you want the info stored. Like so:
dx=varptr(buffer(0)) rem if you don't, this routine will not work,
or will overwrite some rem other section of memory. And for virus
coding, this is very bad! :) rem cx register is how many bytes to
read :) if file_handle>4 then ax=&hex3f00 bx=file_handle
cx=bytesize int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) bytesread=ax
endif return

Hey, just wanted to mention that Linux used to use int86(0x80,...)
for its own syscalls. In C, read(2) is the way to read into a
buffer, which would set up the syscall (call to interrupt 0x80). I
guess in DOS, C would set up the interrupt call similar to how you
show, and then call the interrupt.

I remember from writing elf binaries. <G> Fun and educational times.

Modern processors have an actual SYSCALL intrinsic, so no more
interrupt call to enter the kernel.

Windows API calls can still be used to enter the kernel. Modern CPUs
running a flavor of DOS still respect DOS interrupt calls when
running in 'real mode' kernel entrance. It's known as 'real mode' vs 'Protected mode and virtualization'

As for Linux, here's a c/p from google AI:

Yes, Linux absolutely uses interrupts and interrupt calls (like the
syscall instruction on modern CPUs) to allow user-space processes to
request kernel services, enabling privileged kernel access for tasks
like file I/O or process management, with specific mechanisms like
IRQs for hardware, `syscall` for system calls, and exceptions for
errors all transitioning the CPU to kernel mode (Ring 0) to execute privileged code. Modern systems use efficient instructions like
syscall for system calls, but the core principle of interrupt-driven transitions to kernel space for privileged operations remains
fundamental. ***

The 286 was the first to offer protected mode access. It was
significantly improved with the 386. Modern CPUs still offer real
mode as well. So, I'm not sure what you mean exactly by a modern CPU
in this instance? Or what you mean by no more interrupt call to enter
the kernel?

Exactly. "SYSCALL" is an opcode on x86_64 processors, and from
what I've read, it's faster than using an interrupt. (But don't
quote me on that. ;) )

My main point, though, was the similarity of how DOS handled
things -- it's basically the old-style "syscall" (setting up
registers, maybe some stack, and then raising an interrupt),
even if it wasn't known as a "syscall".

I remember DOS interrupts 0x21 (DOS itself), and 0x10(BIOS, iirc).

<G> It takes me back man.

--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G
OS: Linux 6.18.0 D: Mint 22.2 DE: Xfce 4.18
NVIDIA: 580.105.08 Mem: 258G
"Four minus two is one and the same."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

At Mon, 08 Dec 2025 04:36:08 +0000, vallor <vallor@vallor.earth> wrote:

At Mon, 8 Dec 2025 02:32:39 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

vallor <vallor@vallor.earth> news:10h2u70$36bnl$1@dont-email.me Sun,
07 Dec 2025 04:01:36 GMT in comp.os.linux.advocacy, wrote:

At Wed, 3 Dec 2025 22:03:12 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

read_file: rem as the name implies, it reads bytes into a buffer.
:-) rem as with write_file, you need to predefine the dx register
for the rem buffer where you want the info stored. Like so:
dx=varptr(buffer(0)) rem if you don't, this routine will not work,
or will overwrite some rem other section of memory. And for virus
coding, this is very bad! :) rem cx register is how many bytes to
read :) if file_handle>4 then ax=&hex3f00 bx=file_handle
cx=bytesize int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) bytesread=ax
endif return

Hey, just wanted to mention that Linux used to use int86(0x80,...)
for its own syscalls. In C, read(2) is the way to read into a
buffer, which would set up the syscall (call to interrupt 0x80). I
guess in DOS, C would set up the interrupt call similar to how you
show, and then call the interrupt.

I remember from writing elf binaries. <G> Fun and educational times.

Modern processors have an actual SYSCALL intrinsic, so no more
interrupt call to enter the kernel.

Windows API calls can still be used to enter the kernel. Modern CPUs running a flavor of DOS still respect DOS interrupt calls when
running in 'real mode' kernel entrance. It's known as 'real mode' vs 'Protected mode and virtualization'

As for Linux, here's a c/p from google AI:

Yes, Linux absolutely uses interrupts and interrupt calls (like the
syscall instruction on modern CPUs) to allow user-space processes to request kernel services, enabling privileged kernel access for tasks
like file I/O or process management, with specific mechanisms like
IRQs for hardware, `syscall` for system calls, and exceptions for
errors all transitioning the CPU to kernel mode (Ring 0) to execute privileged code. Modern systems use efficient instructions like
syscall for system calls, but the core principle of interrupt-driven transitions to kernel space for privileged operations remains
fundamental. ***

The 286 was the first to offer protected mode access. It was
significantly improved with the 386. Modern CPUs still offer real
mode as well. So, I'm not sure what you mean exactly by a modern CPU
in this instance? Or what you mean by no more interrupt call to enter
the kernel?

Exactly. "SYSCALL" is an opcode on x86_64 processors, and from
what I've read, it's faster than using an interrupt. (But don't
quote me on that. ;) )

My main point, though, was the similarity of how DOS handled
things -- it's basically the old-style "syscall" (setting up
registers, maybe some stack, and then raising an interrupt),
even if it wasn't known as a "syscall".

I remember DOS interrupts 0x21 (DOS itself), and 0x10(BIOS, iirc).

<G> It takes me back man.

BTW, outlining my thought process:

Saw your call to int86(0x21,...) to read to a buffer.

Recognized that as basically the same as Linux's (old)
syscall mechanism of raising an interrupt to call the kernel ABI.

Looked up the "syscall interrupt" on the net, discovered that it
used to be 0x80, but now newer processors use a new opcode,
"SYSCALL".

...and so forth.
--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G
OS: Linux 6.18.0 D: Mint 22.2 DE: Xfce 4.18
NVIDIA: 580.105.08 Mem: 258G
"If at first you don't succeed, then Sky Diving is not for you!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 2025-12-08, vallor <vallor@vallor.earth> wrote:

At Mon, 08 Dec 2025 04:36:08 +0000, vallor <vallor@vallor.earth> wrote:

At Mon, 8 Dec 2025 02:32:39 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

vallor <vallor@vallor.earth> news:10h2u70$36bnl$1@dont-email.me Sun,
07 Dec 2025 04:01:36 GMT in comp.os.linux.advocacy, wrote:

At Wed, 3 Dec 2025 22:03:12 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

read_file: rem as the name implies, it reads bytes into a buffer.
:-) rem as with write_file, you need to predefine the dx register
for the rem buffer where you want the info stored. Like so:
dx=varptr(buffer(0)) rem if you don't, this routine will not work,
or will overwrite some rem other section of memory. And for virus
coding, this is very bad! :) rem cx register is how many bytes to
read :) if file_handle>4 then ax=&hex3f00 bx=file_handle
cx=bytesize int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) bytesread=ax
endif return

Hey, just wanted to mention that Linux used to use int86(0x80,...)
for its own syscalls. In C, read(2) is the way to read into a
buffer, which would set up the syscall (call to interrupt 0x80). I
guess in DOS, C would set up the interrupt call similar to how you
show, and then call the interrupt.

I remember from writing elf binaries. <G> Fun and educational times.

Modern processors have an actual SYSCALL intrinsic, so no more
interrupt call to enter the kernel.

Windows API calls can still be used to enter the kernel. Modern CPUs
running a flavor of DOS still respect DOS interrupt calls when
running in 'real mode' kernel entrance. It's known as 'real mode' vs
'Protected mode and virtualization'

As for Linux, here's a c/p from google AI:

Yes, Linux absolutely uses interrupts and interrupt calls (like the
syscall instruction on modern CPUs) to allow user-space processes to
request kernel services, enabling privileged kernel access for tasks
like file I/O or process management, with specific mechanisms like
IRQs for hardware, `syscall` for system calls, and exceptions for
errors all transitioning the CPU to kernel mode (Ring 0) to execute
privileged code. Modern systems use efficient instructions like
syscall for system calls, but the core principle of interrupt-driven
transitions to kernel space for privileged operations remains
fundamental. ***

The 286 was the first to offer protected mode access. It was
significantly improved with the 386. Modern CPUs still offer real
mode as well. So, I'm not sure what you mean exactly by a modern CPU
in this instance? Or what you mean by no more interrupt call to enter
the kernel?

Exactly. "SYSCALL" is an opcode on x86_64 processors, and from
what I've read, it's faster than using an interrupt. (But don't
quote me on that. ;) )

My main point, though, was the similarity of how DOS handled
things -- it's basically the old-style "syscall" (setting up
registers, maybe some stack, and then raising an interrupt),
even if it wasn't known as a "syscall".

I remember DOS interrupts 0x21 (DOS itself), and 0x10(BIOS, iirc).

<G> It takes me back man.

BTW, outlining my thought process:

Saw your call to int86(0x21,...) to read to a buffer.

Recognized that as basically the same as Linux's (old)
syscall mechanism of raising an interrupt to call the kernel ABI.

Looked up the "syscall interrupt" on the net, discovered that it
used to be 0x80, but now newer processors use a new opcode,
"SYSCALL".

...and so forth.

Way back in the dark ages I was fascinated by copy protection schemes
that were being used at the time and some of them used undocumented
INT 21h calls.
I found it interesting at the time even though I wasn't a hardcore
gamer.
Well, I did find Lounge Lizard Larry to be quite addictive.
--
pothead
Give a Democrat a fish and he'll eat all day.
Teach a Democrat to fish and......
He'll steal your rod
Take your wallet
Assault the fish &
Blame Trump.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 08/12/2025 23:21, pothead wrote:

Well, I did find Lounge Lizard Larry to be quite addictive.

Leisure Suit Larry.
--
"First, find out who are the people you can not criticise. They are your oppressors."
- George Orwell

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

vallor <vallor@vallor.earth> news:10h5kjp$3tql3$1@dont-email.me Mon, 08 Dec 2025 04:36:08 GMT in comp.os.linux.advocacy, wrote:

At Mon, 8 Dec 2025 02:32:39 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

vallor <vallor@vallor.earth> news:10h2u70$36bnl$1@dont-email.me Sun,
07 Dec 2025 04:01:36 GMT in comp.os.linux.advocacy, wrote:

At Wed, 3 Dec 2025 22:03:12 -0000 (UTC), Gremlin <nobody@haph.org>
wrote:

read_file: rem as the name implies, it reads bytes into a buffer.
:-) rem as with write_file, you need to predefine the dx register
for the rem buffer where you want the info stored. Like so:
dx=varptr(buffer(0)) rem if you don't, this routine will not work,
or will overwrite some rem other section of memory. And for virus
coding, this is very bad! :) rem cx register is how many bytes to
read :) if file_handle>4 then ax=&hex3f00 bx=file_handle
cx=bytesize int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) bytesread=ax
endif return

Hey, just wanted to mention that Linux used to use int86(0x80,...)
for its own syscalls. In C, read(2) is the way to read into a
buffer, which would set up the syscall (call to interrupt 0x80). I
guess in DOS, C would set up the interrupt call similar to how you
show, and then call the interrupt.

I remember from writing elf binaries. <G> Fun and educational times.

Modern processors have an actual SYSCALL intrinsic, so no more
interrupt call to enter the kernel.

Windows API calls can still be used to enter the kernel. Modern CPUs
running a flavor of DOS still respect DOS interrupt calls when
running in 'real mode' kernel entrance. It's known as 'real mode' vs
'Protected mode and virtualization'

As for Linux, here's a c/p from google AI:

Yes, Linux absolutely uses interrupts and interrupt calls (like the
syscall instruction on modern CPUs) to allow user-space processes to
request kernel services, enabling privileged kernel access for tasks
like file I/O or process management, with specific mechanisms like
IRQs for hardware, `syscall` for system calls, and exceptions for
errors all transitioning the CPU to kernel mode (Ring 0) to execute
privileged code. Modern systems use efficient instructions like
syscall for system calls, but the core principle of interrupt-driven
transitions to kernel space for privileged operations remains
fundamental. ***

The 286 was the first to offer protected mode access. It was
significantly improved with the 386. Modern CPUs still offer real
mode as well. So, I'm not sure what you mean exactly by a modern CPU
in this instance? Or what you mean by no more interrupt call to enter
the kernel?

Exactly. "SYSCALL" is an opcode on x86_64 processors, and from
what I've read, it's faster than using an interrupt. (But don't
quote me on that. ;) )

Aha! Now I get what you meant. <G>

My main point, though, was the similarity of how DOS handled
things -- it's basically the old-style "syscall" (setting up
registers, maybe some stack, and then raising an interrupt),
even if it wasn't known as a "syscall".

Gotcha!
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

pothead <pothead@snakebite.com> news:10h7mil$fq1s$1@pothead.dont-email.me Mon, 08 Dec 2025 23:21:57 GMT in comp.os.linux.advocacy, wrote:

Way back in the dark ages I was fascinated by copy protection schemes
that were being used at the time and some of them used undocumented
INT 21h calls.

Yep! Did you ever see any of them rerouting any while they were in use? Sneaky bastages.

I found it interesting at the time even though I wasn't a hardcore
gamer.
Well, I did find Lounge Lizard Larry to be quite addictive.

<G> That series was fun!
Beat the pants off (no pun intended) of Where in the world is Carmen sandiego. --
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 2025-12-08 15:30, vallor wrote:

At Mon, 08 Dec 2025 04:36:08 +0000, vallor <vallor@vallor.earth> wrote:

At Mon, 8 Dec 2025 02:32:39 -0000 (UTC), Gremlin <nobody@haph.org> wrote: >>> vallor <vallor@vallor.earth> news:10h2u70$36bnl$1@dont-email.me Sun,

07 Dec 2025 04:01:36 GMT in comp.os.linux.advocacy, wrote:

At Wed, 3 Dec 2025 22:03:12 -0000 (UTC), Gremlin <nobody@haph.org> wrote:

...

Looked up the "syscall interrupt" on the net, discovered that it
used to be 0x80, but now newer processors use a new opcode,
"SYSCALL".

I asked google, got some answers and an AI summary:

The SYSCALL instruction (opcode 0F 05) is a fast, modern assembly instruction in 64-bit x86 systems used by applications (user-mode, Ring 3) to request services from the operating system kernel (kernel-mode, Ring 0). It efficiently transitions from user to kernel space by saving the return address (RIP) to the RCX register, flipping privilege levels, loading the kernel entry point from a Model Specific Register (MSR), and using the SYSRET instruction to return, replacing the slower INT 0x80 interrupt method for better performance, though security measures like KPTI add overhead.
How it works:

Initiation: A user program executes SYSCALL, often after placing a system call number in RAX and arguments in registers like RDI, RSI, RDX.
CPU Action:
Saves the address of the next instruction (RIP) into RCX.
Saves the RFLAGS into R11.
Loads a new RIP from a special kernel MSR, pointing to the kernel's system call entry code.
Changes privilege level from Ring 3 to Ring 0 (kernel mode).
Kernel Execution: The kernel runs, uses arguments, performs the requested service (e.g., file I/O, process management).
Return: The kernel uses the saved RCX and R11 to execute SYSRET, transitioning back to user mode, restoring registers, and resuming the user program.

Key aspects:

Performance: Much faster than the older INT 0x80 method, crucial for modern OS performance.
Registers: Uses specific registers (RAX for syscall number, RDI, RSI, RDX, R10, R8, R9 for arguments, RCX for return address).
Security: A vital part of OS security, creating a boundary between trusted kernel and untrusted user code.
Context: Part of the SYSCALL/SYSRET pair, optimized for 64-bit systems.

...and so forth.

--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 2025-12-10, Gremlin <nobody@haph.org> wrote:

pothead <pothead@snakebite.com> news:10h7mil$fq1s$1@pothead.dont-email.me Mon,
08 Dec 2025 23:21:57 GMT in comp.os.linux.advocacy, wrote:

Way back in the dark ages I was fascinated by copy protection schemes
that were being used at the time and some of them used undocumented
INT 21h calls.

Yep! Did you ever see any of them rerouting any while they were in use? Sneaky
bastages.

I have heard something about that but personally I don't recall
experiencing it myself. It might explain why I sometimes had difficulties tracing what the code was doing. Expected vs actual results.

I found it interesting at the time even though I wasn't a hardcore
gamer.
Well, I did find Lounge Lizard Larry to be quite addictive.

<G> That series was fun!
Beat the pants off (no pun intended) of Where in the world is Carmen sandiego.

I never understood the fascination with that game.
Maybe I missed the point?
--
pothead
Give a Democrat a fish and he'll eat all day.
Teach a Democrat to fish and......
He'll steal your rod
Take your wallet
Assault the fish &
Blame Trump.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Dec 10, 2025 at 11:13:25 AM MST, "pothead" wrote <10hcd85$1m977$1@pothead.dont-email.me>:

Give a Democrat a fish and he'll eat all day.
Teach a Democrat to fish and......
He'll steal your rod
Take your wallet
Assault the fish &
Blame Trump.

Your sig isn’t an argument; it’s a slogan that falls apart against basic facts. Blue states contribute more in federal taxes than they receive, Trump’s
record includes verified court rulings and fiscal mismanagement, and violent crime rates are generally higher per capita in Republican-led states. The joke relies on caricature and repetition rather than evidence, substituting
sneering for substance. Typical of White Nationalists.

While it contains no explicit racial language, it overlaps with common white supremacist rhetorical patterns. It frames an out-group as inherently criminal and parasitic, uses mockery and “just a joke” humor to deflect scrutiny, flattens millions of people into a single corrupt mass, and recasts grievances as moral righteousness. That’s the same toolbox extremist movements use to spread ideas indirectly – not by arguing facts, but by normalizing contempt.

You keep denying you tie yourself to such groups, but then you show you DO tie yourself to them.

Over and over and over.
--
It's impossible for someone who is at war with themselves to be at peace with you.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

pothead <pothead@snakebite.com> news:10hcd85$1m977$1@pothead.dont-email.me
Wed, 10 Dec 2025 18:13:25 GMT in comp.os.linux.advocacy, wrote:

On 2025-12-10, Gremlin <nobody@haph.org> wrote:

pothead <pothead@snakebite.com>
news:10h7mil$fq1s$1@pothead.dont-email.me Mon, 08 Dec 2025 23:21:57 GMT
in comp.os.linux.advocacy, wrote:

Way back in the dark ages I was fascinated by copy protection schemes
that were being used at the time and some of them used undocumented
INT 21h calls.

Yep! Did you ever see any of them rerouting any while they were in use?
Sneaky bastages.

I have heard something about that but personally I don't recall
experiencing it myself. It might explain why I sometimes had
difficulties tracing what the code was doing. Expected vs actual
results.

I found it interesting at the time even though I wasn't a hardcore
gamer.
Well, I did find Lounge Lizard Larry to be quite addictive.

<G> That series was fun!
Beat the pants off (no pun intended) of Where in the world is Carmen
sandiego.

I never understood the fascination with that game.
Maybe I missed the point?

It was supposed to be a teaching aid for geography and reading comprehension. While it was somewhat succesful in both of those, as a whole, it was a lame
as frak game to spend any real time with.
--
Liar, lawyer; mirror show me, what's the difference?
Kangaroo done hung the guilty with the innocent
Liar, lawyer; mirror for ya', what's the difference?
Kangaroo be stoned. He's guilty as the government

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 12/12/2025 6:44 pm, Gremlin wrote:

pothead <pothead@snakebite.com> news:10hcd85$1m977$1@pothead.dont-email.me Wed, 10 Dec 2025 18:13:25 GMT in comp.os.linux.advocacy, wrote:

On 2025-12-10, Gremlin <nobody@haph.org> wrote:

pothead <pothead@snakebite.com>
news:10h7mil$fq1s$1@pothead.dont-email.me Mon, 08 Dec 2025 23:21:57 GMT
in comp.os.linux.advocacy, wrote:

Way back in the dark ages I was fascinated by copy protection schemes
that were being used at the time and some of them used undocumented
INT 21h calls.

Yep! Did you ever see any of them rerouting any while they were in use?
Sneaky bastages.

I have heard something about that but personally I don't recall
experiencing it myself. It might explain why I sometimes had
difficulties tracing what the code was doing. Expected vs actual
results.

I found it interesting at the time even though I wasn't a hardcore
gamer.
Well, I did find Lounge Lizard Larry to be quite addictive.

Wasn't it "Leasuresuit Larry in the Land of the Lounge Lizards"!! (Did
all the Devs have a name beginning with 'L' or something??)
--
Daniel70
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On 12/12/2025 11:39, Daniel70 wrote:

On 12/12/2025 6:44 pm, Gremlin wrote:

pothead <pothead@snakebite.com>
news:10hcd85$1m977$1@pothead.dont-email.me
Wed, 10 Dec 2025 18:13:25 GMT in comp.os.linux.advocacy, wrote:

On 2025-12-10, Gremlin <nobody@haph.org> wrote:

pothead <pothead@snakebite.com>
news:10h7mil$fq1s$1@pothead.dont-email.me Mon, 08 Dec 2025 23:21:57 GMT >>>> in comp.os.linux.advocacy, wrote:

Way back in the dark ages I was fascinated by copy protection schemes >>>>> that were being used at the time and some of them used undocumented
INT 21h calls.

Yep! Did you ever see any of them rerouting any while they were in use? >>>> Sneaky bastages.

I have heard something about that but personally I don't recall
experiencing it myself. It might explain why I sometimes had
difficulties tracing what the code was doing. Expected vs actual
results.

I found it interesting at the time even though I wasn't a hardcore
gamer.
Well, I did find Lounge Lizard Larry to be quite addictive.

Wasn't it "Leasuresuit Larry in the Land of the Lounge Lizards"!! (Did
all the Devs have a name beginning with 'L' or something??)

That was indeed the first one

And IIRC Leisure Suit Larry goes Looking for Love was another.

https://en.wikipedia.org/wiki/Leisure_Suit_Larry

Has more.
--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan


--- Synchronet 3.21a-Linux NewsLink 1.2