VOGONS

Search

Common searches

Search results

Display options

Display options

Re: x86 conforming access rights?

Posted on 2019-04-27, 19:20

It's intended to protect against code returning from low privilege to high privilege, so RPL of 0 and DPL of 3 should fault. Strangely enough, Bochs doesn't seem to check that case(it simply passes said check always with conforming segments during task switches)? In Bochs, having a task with CS.RPL …

x86 conforming access rights?

Posted on 2019-04-27, 15:21

Strangely enough, looking at Bochs' tasking.cc, it doesn;t check CS privilege when it's conforming? The 80386 programmer's reference manual says this: - The conforming bit of the target code-segment descriptor is set, and the DPL of the target is less than or equal to CPL. So when DPL is greater …

x86 V86 mode 16-bit interrupt descriptor?

Posted on 2019-04-26, 13:19

What happens when a 16-bit trap gate is used from V86 mode? What is the width of the segment registers(GS,FS,DS,ES) and SS and ESP that's pushed on the stack? Are they just pushed as 16-bit values(so essentially a PUSH GS, PUSH FS, PUSH DS, PUSH ES, PUSH SS, PUSH SP instructions)? Or are some or all …

Re: Software for debugging Windows 95's first boot?

Posted on 2019-04-25, 17:08

One simple question: doesn't installation of the Soft-ICE program require Windows to have been started for the installer to run? So that creates a chicken-and-egg problem: I can't start Windows, because it's past the first boot phase at that point(stuff of the OS has been edited during the first …

Re: Software for debugging Windows 95's first boot?

Posted on 2019-04-25, 13:22

Can Soft-ICE be installed BEFORE Windows performs it's first boot(From MS-DOS 7.x or manually)? If it can't it's useless in my case, since UniPCemu can't get past the "Initializing KERNEL" phase, according to bootlog.txt. All I see is a Windows installer(which can't be used in UniPCemu's case?). …

Software for debugging Windows 95's first boot?

Posted on 2019-04-21, 20:40

Is there any software that can be used for debugging Windows 95's first boot(a debugger that can be loaded into memory before Windows starts that lets me actually know what driver is going honky)? It still crashes in my emulator when Windows 95 is booting for the first time, at the "Initializing …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-21, 20:26

Also, some interesting trivia. Found some proof that Windows 95 also uses Expand-Down segments(to prevent Windows 95 applications from accessing the MS-DOS VM and shared 4MB area(for Windows 3.x programs)): Geek trivia: To prevent Win32 applications from accessing the MS-DOS compatibility area, the …

Re: UniPCemu Windows 95/NT progress and issues

Posted on 2019-04-21, 15:24

Hmmm.... Interestingly enough, I see Windows 95 crashing on opcode 89 46h (some MOV instruction) in protected mode only(due to a Page Fault on some address within the low memory hole range(A0000-FFFFF) that has a PTE of 0?)? The only thing fixed is the CR registers no longer faulting on afaik. Edit: …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-20, 23:36

Ehm..... Offset 0xffff isn't what I was talking about. I clearly stated offset 0xffff for the 64K one and offset 0xffffffff for the 4G one. So, for offset FFFFh in a 64K expand-down segment with limit field set to 0 and offset FFFFFFFFh in a 4G expand-down segment with a limit field set to 0 won't …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-20, 22:00

So, for offset FFFFh in a 64K expand-down segment with limit field set to 0 and offset FFFFFFFFh in a 4G expand-down segment with a limit field set to 0 won't point to the same address in memory? Huh? Sure they would. The small segment would be valid from base+1 - base+64K and the large from base+1 …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-20, 20:58

So, for offset FFFFh in a 64K expand-down segment with limit field set to 0 and offset FFFFFFFFh in a 4G expand-down segment with a limit field set to 0 won't point to the same address in memory? For a 64K, it would point to base+FFFFh, while for a 4G it would point to the byte immediately below the …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-20, 20:43

Looking at http://premium.caribe.net/~adrian2/docs/exc_ia.pdf page 8 seems to agree with the documentation and my logic. Indeed, as you can see in the diagram on said page, the final byte of the segment descriptor(at offset FFFFh in 64K granuliary) is actually located at the address set in the base …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-20, 19:55

Well, the documentation I gave on the first post says something interesting on it: Sometimes the arithmetic is dependent upon the B (Big) bit in the DTE. This bit controls several aspects of how the CPU interprets the Base, Limit, and Valid Offsets of a selector. As you can see from the table below, …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-20, 19:13

Or is the offset 1-extended to 32-bits before adding it(as long as it's obeying the segment descriptor's limit(being more than the limit field(which is 1-appended for 4K segments(Granularity being 4K))) and roof of 64K/4G), resulting in a offset of FFFFFFFC(wrapping afterwards), thus resulting in a …

Re: x86 address calculation for expand-down segments?

Posted on 2019-04-20, 19:08

crazyc wrote: superfury wrote: Is the expand-down segment's linear address calculated differently from expand-up segments? No. So, the result of a base address of 0x80000000 and limit 0xFFFF, then addressing offset 0xFFFC actually resolves to linear address(or physical address without paging) …

Page 83 of 229

Go to top of page Go to top of page
Close window
Close window