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!
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!
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?
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?
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.
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
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
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?
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?
The Svin - having read your posts, I guess this is going to surprise you
I've got:
Win95 016fh
Win98 SE 0167h
Regards
eGo
I've got:
Win95 016fh
Win98 SE 0167h
Regards
eGo
Surprizing indeed :)
Thanx.
I'm waiting for the other's data.
Thanx.
I'm waiting for the other's data.
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.
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.
Hello,
On my NT 4.0 (fr), got cs = 001bh
On my NT 4.0 (fr), got cs = 001bh
Windows XP Professional, English (USA), CS = 001Bh
I guess, all NT kernel based OSs have 01B as code segment selector, while 9x may differ from each others.
Just not sure what to do. Just get the context of CS? Of what process?
Load in debugger any user mode Win32 app.
And look up value in CS.
Then, please, post it here along with you OS name.
And look up value in CS.
Then, please, post it here along with you OS name.
and what can we learn from this? don't use hardcoded stuff even though it might seem very unlikely that it will change.
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.
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.
win2K here: 001b
Win2k AS cs=001bh
WinME cs=0187h
WinME cs=0187h
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.
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.
.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.
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.
I don't believe 0 is a valid selector.
Assuming I understand what your DisplayregXXX does, what does the following produce?
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