Ok, I've tried it now, and I got it to work!

The problem was that the segment part of the address should be 01A7h, and not 0227h. So I guess that it is not the same on all Windows 9x systems after all.

Also, it is possible to jump to any address, dword aligned or not, I checked.

Thanks everyone!

If I now could just find out how these segments really work in Windows, and I'd be all happy. Does anyone have a suggestion of a good place to acquire this kind of information (article or thread)? That would be really great anyway.

Thanks!
Posted on 2003-02-14 17:14:03 by dELTA
Well I'm even less familiar than you about segment's. So i cant really say anything about the behaviour of CS for certain. but while i was watching it it never changed from 0x0008 on my windows xp system
however when I attempted to hardcode that value in the prog it still did not work, this is a question for ppl more experienced than myself
I would also love info on segments. any one know of a tut that explains the purpose and proper usage of segment registers?
Posted on 2003-02-14 17:28:11 by dionysus

Ok, I've tried it now, and I got it to work!

The problem was that the segment part of the address should be 01A7h, and not 0227h. So I guess that it is not the same on all Windows 9x systems after all.

Also, it is possible to jump to any address, dword aligned or not, I checked.

Thanks everyone!

If I now could just find out how these segments really work in Windows, and I'd be all happy. Does anyone have a suggestion of a good place to acquire this kind of information (article or thread)? That would be really great anyway.

Thanks!


Hmm. Interestig. 98 and CS=01A7?
I saw hundreds 98s all had 0227.
Well, I'm glad you finally placed value in CS into jmp far
format.
Posted on 2003-02-17 03:53:11 by The Svin
dionysus,

properly, segments do not figure in 32 bit flat memory model but as MASM in particular was designed back in the segmented architecture days of 16 bit DOS, there are still a few fudges that can be used where the old code segment and data segment technology lines up with a modern PE code SECTION and data SECTION.

These are basically anachronisms left over in MASM for compatibility reasons, the PE standard does not use segments at all and the segments in a flat memory model OS like Windows are all set at the same start address.

As far as learning the segmented arachitecture of ntel processors, the Intel manuals are the best I know of for this data. Even though this technology is rarely used these days, x86 processors have the capacity to run segments and from memory, they can even run 32 bit segments if you wrote the OS to do it.

Regards,

hutch@movsd.com
Posted on 2003-02-17 05:51:11 by hutch--
Could everybody here give me a favor:
Please: please, post what is your OS (if your OS is Win32 family) and what is in CS register of loaded user mode level Win32 app?
Posted on 2003-02-17 16:04:40 by The Svin
The Svin - having read your posts, I guess this is going to surprise you
I've got:

Win95 016fh
Win98 SE 0167h

Regards
eGo
Posted on 2003-02-17 17:43:16 by eGo
Surprizing indeed :)
Thanx.
I'm waiting for the other's data.
Posted on 2003-02-17 17:45:13 by The Svin
Win2k Professional, English (USA), under VC debugger 001Bh
Don't know if this is the same when not in the debugger. This particular system I'm using doesn't have MASM installed on it.
Posted on 2003-02-18 02:40:04 by tenkey
Hello,

On my NT 4.0 (fr), got cs = 001bh
Posted on 2003-02-18 09:34:55 by etherlord
Windows XP Professional, English (USA), CS = 001Bh
Posted on 2003-02-18 15:57:21 by tenkey
I guess, all NT kernel based OSs have 01B as code segment selector, while 9x may differ from each others.
Posted on 2003-02-18 16:34:04 by The Svin
Just not sure what to do. Just get the context of CS? Of what process?
Posted on 2003-02-18 19:22:41 by mrgone
Load in debugger any user mode Win32 app.
And look up value in CS.
Then, please, post it here along with you OS name.
Posted on 2003-02-19 04:15:51 by The Svin
and what can we learn from this? don't use hardcoded stuff even though it might seem very unlikely that it will change.
Posted on 2003-02-19 04:55:48 by f0dder
From this we learn factual data.
Those who respect people (they converse to) leave a choise
to use the data and make conclusions to the people.
Such manners to talk fit to cusaders section not here, f00der.

'Cause the first question here whom do you mean by "We"?
"We" are so different, f00der, and write such different code, for
such different purpose, machines, environment, conditions etc.
so it looks like kinda disrespect to give "universal" advises for "US".

In opposite pure and precise technical data is interesting and informative
for low level coders. What they are going to do with that - is their business.

The man asked qeustion - how he could use far jump opcode in his Win32 app.
We are trying to help him understand it and collecting data related to it.

How your post relates to it - I just can not see.
It fits to crusaders " war for nothing" talks.
Posted on 2003-02-19 07:40:14 by The Svin
win2K here: 001b
Posted on 2003-02-19 08:01:42 by Hiroshimator
Win2k AS cs=001bh
WinME cs=0187h
Posted on 2003-02-19 10:14:58 by pelaillo
win2k+sp3, cs=0x1b.

don't get me wrong svin, doing absolute jumps like that is fine if you know
what you're doing... which I pretty much assume you are ;). but I've seen
hardcoded addresses in some "production quality" software. I've seen win32
apps doing direct port I/O. That is obviously _not_ a good thing.

Same as not calling InitCommonControls. it works now, and might continue
working, but who knows if microsoft decides to make it actually do something?
Something required? Imho, if you want to do (consumer) win32 programming,
you should play by microsofts rules. Incompatible software is annoying.
Posted on 2003-02-19 10:27:24 by f0dder
.elseif DBEvent.dwDebugEventCode==CREATE_PROCESS_DEBUG_EVENT
invoke wsprintf, addr buffer, addr ProcessInfo, DBEvent.u.CreateProcessInfo.hFile, DBEvent.u.CreateProcessInfo.hProcess, DBEvent.u.CreateProcessInfo.hThread, DBEvent.u.CreateProcessInfo.lpBaseOfImage, DBEvent.u.CreateProcessInfo.lpStartAddress
invoke MessageBox,0, addr buffer, addr AppName, MB_OK+MB_ICONINFORMATION

invoke SuspendThread,pi.hThread
invoke GetThreadContext,pi.hThread, addr context
push eax
mov eax,context.regCs
mov regXXX,eax
call DisplayregXXX
pop eax
invoke ResumeThread,pi.hThread

This was the order I did it in and I got a "0" in CS.
Posted on 2003-02-19 12:04:02 by mrgone
I don't believe 0 is a valid selector.

Assuming I understand what your DisplayregXXX does, what does the following produce?

mov ax,cs            ; get current CS

and eax,0FFFFh ; zero out high bits
mov regXXX,eax ; store in argument variable
call DisplayregXXX ; display result
Posted on 2003-02-19 14:24:15 by tenkey