flat assembler
Message board for the users of flat assembler.

Index > DOS > problem with unREAL mode fasm

Goto page Previous  1, 2, 3, 4, 5
Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 19 Feb 2009, 09:57
Tomasz Grysztar wrote:
I don't plan any more work in


No problem. I meant "do-it-myself" anyway.

Quote:
Reverting to own DPMI implementation wouldn't be such a good choice, since there are really much better DPMI implementations available out there.


None in FASM.

Quote:
There was once this guy that made fasm interface to work with VCPI, but it wasn't very good and is forgotten now.


OK. I don't love VCPI anyway.

Quote:
option I see where the current solution could be improved is to make it scan (in case when no DPMI host is loaded) the PATH directories for one of the known DPMI host executables (like CWSDPMI.EXE


Better keep as-is.

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 19 Feb 2009, 09:57
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 24 Feb 2009, 07:13
DOS386 wrote:
Tomasz Grysztar wrote:

option I see where the current solution could be improved is to make it scan (in case when no DPMI host is loaded) the PATH directories for one of the known DPMI host executables (like CWSDPMI.EXE


Better keep as-is.


I disagree, searching for CWSDPMI or HDPMI32 would be a good idea, IMHO (or even CWSDPR0 if you really want to avoid swapping). You could always make this configurable via environment variable like EMX and RSX do: "set EMX=c:\dos\rsx.exe" will force RSX (DPMI) instead of EMX (VCPI). So "set DPMI=MWDPMI" (or whatever) could override the default search. Then again, I guess nobody will die with the current setup. But I don't think it's a bad idea to try loading one (as all DJGPP apps do, and nobody complained, but it's configurable too).
Post 24 Feb 2009, 07:13
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 24 Feb 2009, 08:05
rugxulo wrote:
searching for CWSDPMI or HDPMI32 would be a good idea


In reversed order at worst Sad

Quote:
You could always make this configurable via environment variable like EMX and RSX do: "set EMX=c:\dos\rsx.exe" will force RSX (DPMI) instead of EMX (VCPI). So "set DPMI=MWDPMI" (or whatever) could override the default search.


EMX + RSX dead stuff again ...

I prefer a clear "No DPMI host" message from silent searches sensitive to 1'000'000 undocumented enviral variables with unpredictable results and all the CWSDPMI.SWP, buggy CWSDPMI versions and related mess Sad

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 24 Feb 2009, 08:05
View user's profile Send private message Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 01 May 2009, 08:11
I'd like to have the last DOS fasm version which runs in unreal mode. Which one is it? Can someone provide it? Thank you
Post 01 May 2009, 08:11
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 02 May 2009, 10:03
Either wait for 1.68 or use something like 1.67.23 (or maybe .37, I forget).
Post 02 May 2009, 10:03
View user's profile Send private message Visit poster's website Reply with quote
Czerno



Joined: 02 Jun 2009
Posts: 8
Czerno 02 Jun 2009, 09:06
This thread is old but I'm a newcomer so please let me resurrect it.

What is the problem anyway ? There may be a misunderstanding here, but
are you (Thomasz) saying that you are blocked from expanding the code segment over 64 k in "huge" real mode (CS.D=1) ?

That doesn't need to be so. True, the processor doesn't auto-save the high part of EIP on interrupts, but the "user level" code itself can save that to a convenient system-accessible place whenever it changes and be restored by the 2-stage interrupt return code.

A 'convenient' place to store high EIP often means the CR3 (but I think you are using it for another purpose) or CR2 but could be to a fixed place in low memory, too.

You organise the user code inside of 64 k byte large sections (pseudo-segments, so to say) such that each section has a relatively small number of entry from the other section(s). Whenever jumping ('near' jumping of course) between different sections, adjust the saved high EIP.

Pray tell, guys, does this make sense for FASM ?
Post 02 Jun 2009, 09:06
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 02 Jun 2009, 11:28
There are even simpler solution that do not require using huge EIP at all. The only problem is that fasm's source are written in an OS-independent way which makes any tricks a bit harder to do.

Still, I already designed a good method to deal with this in future, when needed (for now fasm's code still fits into the 64k). So this thread is really obsolete now.
Post 02 Jun 2009, 11:28
View user's profile Send private message Visit poster's website Reply with quote
Czerno



Joined: 02 Jun 2009
Posts: 8
Czerno 02 Jun 2009, 16:14
Tomasz Grysztar wrote:
There are even simpler solution that do not require using huge EIP at all. The only problem is that fasm's source are written in an OS-independent way which makes any tricks a bit harder to do.


Sure!

Quote:
I already designed a good method to deal with this in future, when needed (for now fasm's code still fits into the 64k).


Thank you, keep the good work done ! and please keep us updated.

Quote:
So this thread is really obsolete now.


I hoped we could talk about VMware (in)compatibility with exotic real modes, since there is no good way to report bugs to them unless you have a support contract. Should i open a new thread, or is it off topic on the here board ?

Regards

--
Czerno
Post 02 Jun 2009, 16:14
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 04 Jun 2009, 14:11
> Either wait for 1.68 or use something like 1.67.23

Get 1.67.29 Wink

> I hoped we could talk about VMware (in)compatibility with exotic real modes

Better run DOS natively Wink

Tomasz wrote:

> Still, I already designed a good method to deal with this in future,
> when needed (for now fasm's code still fits into the 64k).

So it will be in 1.68 ? Please look into the IDE BUG also Wink

> So this thread is really obsolete now.

NOT yet.
Post 04 Jun 2009, 14:11
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 04 Jun 2009, 14:37
DOS386 wrote:
So it will be in 1.68 ?

There is no need for it to be applied to 1.68, because right now the code still fits under the limit.
Post 04 Jun 2009, 14:37
View user's profile Send private message Visit poster's website Reply with quote
Czerno



Joined: 02 Jun 2009
Posts: 8
Czerno 06 Jun 2009, 07:58
Folks ! Are there any X86 virtualisation systems that cope with FASM huge real mode properly ? Care to test, anyone ?

VMware fails, Virtual PC fails as well (tested VPC 5.1. I have little hope newer MS VPC might fare better).

Bochs (emulator, not a VM; slow!) does well !

Please report test results under other VMs that can boot a DOS (Virtual BOX/Parallels/QEMU...)

Testing is easy : boot a VM to DOS from a real or virtual floppy containing a copy of FASM - real mode DOS, no expanded memory manager - From the DOS command line :
a) launch FASM (no parameters) : it should print its help message.
b) (optional) check if it can FAsSeMble a short "hello world" sample.

What gives ?
Post 06 Jun 2009, 07:58
View user's profile Send private message Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 314
Mac2004 06 Jun 2009, 08:21
Czerno: How about Virtualbox? I haven't tested it by myself, though...

Regards,
Mac2004
Post 06 Jun 2009, 08:21
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 06 Jun 2009, 10:11
> VMware fails, Virtual PC fails as well

Good.

> Bochs (emulator, not a VM; slow!) does well !

Good.

> a) launch FASM (no parameters) : it should print its help message.
> b) (optional) check if it can FAsSeMble a short "hello world" sample.

Don't forget c): self-compiling the commandline version and the IDE from the IDE Smile

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 06 Jun 2009, 10:11
View user's profile Send private message Reply with quote
Czerno



Joined: 02 Jun 2009
Posts: 8
Czerno 06 Jun 2009, 14:17
DOS386 wrote:
> VMware fails, Virtual PC fails as well

Good.


You're being facetious, obviously. Yet there are evident security implications in the VM managers loosing control here : NO good, in my book.


--
Czerno
Post 06 Jun 2009, 14:17
View user's profile Send private message Reply with quote
Czerno



Joined: 02 Jun 2009
Posts: 8
Czerno 08 Jun 2009, 11:24
Though I'm not a regular VBox user, just set up a tiny DOS box for the experiment :

AMD Sempron 2400 / PCLinuxOS /VBOX 2.1.2 (no hardware virtualisation) / DOS 7.1 / FASM 1.67.29

Fantastic ! VirtualBOX executes FASM huge real mode code without a hickup !

Now come on guys, go test this in the other virtual systems ! XEN anybody ?

Also, can someone repeat my tests but with hardware virtualisation on (VT and the like) ?
I don't have the adequate processors...

Cheers Very Happy
Post 08 Jun 2009, 11:24
View user's profile Send private message Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 314
Mac2004 12 Jun 2009, 03:48
Czerno wrote:
Fantastic ! VirtualBOX executes FASM huge real mode code without a hickup !


Excellent!

Regards
Mac2004
Post 12 Jun 2009, 03:48
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.