Limitations of the FAR Jump

[baltoro]

I'm a novice to assembly programming,...everything I know, I got from: "Assembly Language for Intel-based Computers", by Kip Irvine, and, of course, the Intel Developers Guides. Irvine's book is somewhat obsolete; lots of code for DOS 16-bit programs (which you can't run on Windows XP), and mostly simple techniques demonstrating the most often used aspects of assembly programming.
I was reading with great interest the section on interrupts and the DOS interrupt codes, and then, he states that interrupt processing in 32-bit protected mode is possible, but, beyond the scope of the book.
What I'd like to do is write an assembly program (that runs in user mode, not kernel mode) that can access the interrupt table (just to enumerate the interrupt-gate descriptors). Is this possible? Is this too difficult for a novice? Is my conceptual thinking completely whacked?   
Also, I'm interested in just what restrictions are imposed from a hardware and system architecture perspective on the capabilities of FAR jump instructions. I realize that it is impossible to jump into kernel mode, and that I should be restricted from write access of another process's virtual memory. Also, the issue of segment selectors confuses me. Is it possible to execute a FAR Jump without a segment reference? Is this legal, or safe, even preferable? I'm writing for windows XP, and I'll probably integrate the code into a C++ program. 
Thanks.

[dedndave]

   First, let me start by saying it would be to your advantage to learn 32-bit API code.
It is not that difficult, although, it is good to also have a grasp of 16-bit code, as well.
   Next, in 16-bit mode, it is very simple to look into the interrupt table, especially if
all you want to do is read the interrupt vector addresses. It is best to use the DOS
function calls to alter the interrupt table, however, it can be done directly. I am not
sure if XP will generate a fault error, but in the old days of DOS, it was simply a
matter of using a CLI instruction just prior to modifying a vector, and an STI instruction
afterward.
   Finally, the FAR JMP instruction is used to change from one code segment to another,
usually. The only limitation is, there should be some valid code in place when you get
there - lol. When a FAR JMP or FAR CALL is executed, the CS segment register is
changed, as well as the IP register. When a NEAR JMP or NEAR CALL is executed, the
CS register remains unaltered.

This code creates a copy of the Interrupt Vector Table. It will work fine under DOS.
Under Windows, I think you need to play with some additional registers, or the
global descriptor table to get the job done. This is all part of a protected mode OS,
that I am just now learning about, myself. Also, under Windows, the interrupt vector
table may be inaccessible, that's why it is called "protected mode".

(assuming that the DS segment currently
points to the segment that contains BUFFER)

MOV CX,200h
MOV DI,offset BUFFER
XOR SI,SI
PUSH DS
POP ES
PUSH DS
MOV DS,SI
REP MOVSW
POP DS
.
.
.
BUFFER dw 512 dup(?)
.
.

the interrupt vector table is copied into BUFFER

[baltoro]

dedndave,
Thanks for response, however, both my assembly intro book and numerous posters here on the MASM forum tell me that DOS 16-bit real mode code will NOT run on Windows XP.

[BlackVortex]

Windows use some sort of DOS emulation. Interrupt handling is handled transparently by Windows or something like that. Most things work, just don't try to do anything complicated like direct disk writing or similar.

[tetsu-jp]

DOS is abandoned since VISTA.
no DOS program can be executed at all.
using modern VS, no access to segment selectors at all.

don't write this type of software, unless it runs on legacy machine for some purpose.

under VISTA you do not have to deal with system programming anymore, indeed, you can't.

the techniques are indeed obsolete.

as a novice there are more interesting aspects than low-level system programming.
do you want to design your own OS? many assembly beginners have such plans.

[BlackVortex]

DOS is abandoned since VISTA.

Good to know. He said he's using XP, so he's free to do what he wants on his OS, unless he "upgrades"  :toothy

[tetsu-jp]

I have understood Microsoft now has put a lot of effort into virtualization, cloud computing, and remote services.

they do not longer query about low-level.

topics are (for instance) database-type services, which are leased using special licensing models,
"Virtual Earth", "LINQ", and if you want, "auto-complete inside VS", "POPFLY", and "Silverlight".

the new LIVE MOVIE MAKER is not so good on my computer- i think you need a 1-gigabyte graphics card for that.

what i want to say, they have more or less abandoned DOS, interrupts, WIN95/WIN98.

these systems are no longer relevant for Microsoft. they neither offer support, documentation, or "lifetime software buy".
and if you search for a few of the above technologies, you understand eventually.

MASM remains, somehow relevant, an esoteric piece of software.

but what they really talk about (at MS) is web services, virtualization, and data base queries.

all these things completely independent from machine level!

[GregL]

DOS is abandoned since VISTA.

Not true, 16-bit DOS code runs fine on 32-bit Vista.  You must be thinking of 64-bit Windows, where it is not supported.

Sorry, but the rest of the post is hogwash too.

[tetsu-jp]

DOS is abandoned since VISTA.

Not true, 16-bit DOS code runs fine on 32-bit Vista.  You must be thinking of 64-bit Windows, where it is not supported.

Sorry, but the rest of the post is hogwash too.

It does not run on my machine. the others are, you named it, hogwash.

IT IS LEGACY TECHNOLOGY, no longer relevant. simply, think of it as obsolete.

for Microsoft, MSDOS does not even exist.

[brethren]

I concur, the 16-bit code from kip irvines's book runs fine using vista
http://en.wikipedia.org/wiki/Virtual_8086_mode

[tetsu-jp]

yes, fine.
any new 32bit PENTIUM/AMD processors?

so it's legacy soon.

you mean, the code runs in a DOS window?
and this is virtual 8086 mode?

you can't be seriously working Windows via 16bit interrupts (especially USB, 3D graphics, large hard drives).

I've made some VESA programs 5 years ago, and it was bad practice/obsolete technology, back then.
I would not consider this type of programming right now.

I mean, what's the point to documentate VESA legacy, when most of the modes do not work correctly anyway.

wikipedia references are not relevant for me, neither their "product guides".

[GregL]

tetsu-jp,

I haven't written any 16-bit DOS programs for many years.  I'm not trying to defend it, I'm just saying what you posted is not true.

[tetsu-jp]

OK let's be friends, or at least, try to cooperate a little.

I've used MSDOS TC++ myself recently, on WIN98SE. so i know DOSBOX.

reading this, I'd just say "urky and kurky", or smt. the like- can this be serious?
http://www.microsoft.com/windowsxp/using/64bit/bowman_05nov07.mspx

[dedndave]

I would not say DOS has been abandonded - perhaps MS has, but there will always be someone who wants to
use it and will force it to happen. I understand that Vista-64 does not support it, but it won't be long before
someone writes a DOS shell that will run under Vista-64. For all I know it already exists with things like DOSBox.
In a way, I miss the simplicity of 16-bit ASM - lol. But, I am learning to write 32-bit code and I am finding it
very powerful and enjoyable. There's just alot of it to absorb. I do have a few programs that I wrote long ago
that still run under 32-bit OS's. Thank heavens. I would hate to re-write all that stuff. To be honest, what
forced me to learn 32-bit code was that I wrote a small program that would not run on someones 64-bit
Vista machine. Even though Vista-64 is currently in use by less than 5%, I know that number will grow.
I still think it is a good idea for newcomers to have an idea of what 16-bit programming is about. I would
suggest they not spend too much time on it, however, as they have a job ahead of them learning 32-bit.

P.S. i will go throw a blanket over my old XT before any of you guys see it - lol

[tetsu-jp]

I have 16bit DOS project: http://cid-fa090a35b45c1a08.skydrive.live.com/self.aspx/hitech%20products/C%20source%20codes%201.zip

and also i have special hardware switch for LC panel, keyboard, mouse.

by the way DOS is more strange, it only allows 1MB, and it forces people to use segmentation.

TC++ can only use .286 assembly!

for Windows98SE (32bit C++), the segment registers do not need any modification, they are set by the executeable/program loader.
don't modify them!

i think CS: is always taken for program code. data address is defined using ESI/EDI.

only real guru's need to modify segment registers.

it is questionable to learn the 286/386 protected mode programming, segment selectors, descriptors, interrupt gate, and so on!
at least, for beginner.

this was done in the 1990s, and resulted in some questionable DOS-Extenders!
questionable, because sometimes they did work, sometimes not.
and this was done by professional programmers.

the Intel architecture is easy to start off but has depth that can be hell for professionals (simply, the code will occasionally not work as intended).

luckily there is Windows, and the need for DOS extenders is gone!

real-mode interrupts/Windows are deprecated technology. protected mode interrupts?
WHY DO YOU WANT TO DO THIS?
CAN IT BE DONE A DIFFERENT WAY?

from what i know, modern code does not use segment registers anymore, and old code is using CS: by default.

you could take a look at DOS extenders, there are some available as source.
It's quite scary, tough, and not always fully implemented.

or you can use WINUAE, and have all the 32bit freedom on emulated 68000 platform (there are no DOS extenders, segment registers etc.)

what you are looking at is not a good approach to learn machine language (in my opinion), except you want to write a certain type of application THAT ULTIMATIVELY NEEDS TO ACCESS THE SYSTEM LEVEL.