merge devel and release something

Hi.
I think enough is enough, and I am going to merge
devel branch into master and then perhaps upload
the tarballs.
People do not know about the devel branch, but it
works much better than master.
The only reason I didn't merge devel before, is because
it has this commit:
https://sourceforge.net/p/dosemu/code/ci/a1dff2a15698efc4f400812993ec819ea7091439/
which Bart called a re-licensing. I of course do not
want to do any re-licensing, but the intention of that
change is to allow contributing under "GPLv2 or later".
We already have enough of such a code (all my code,
and not only that), so that clause I removed, was
invalidated long ago. There is simply no other way than
to remove it.
So if there is no evidence this is something that should
not be done, I am going to merge things. devel right
now includes over a year of development! It can't be
allowed to rot.
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk

Re: Running win.com from Chicago (alpha version of Win95)

03.06.2014 22:31, Eric Auer пишет:
> Hi!
>
>> The proper win31 support happened because an author of hx
>> extender shared a few tricks with us how to do that. That even
>> involved things contradicting with the dpmi specs. He wrote
>> hdpmi server that was able to run win31 before dosemu did.
> Interesting! When was that and which anti-specs features
> were required? Maybe you can email details to the list?
Eric, there is no secret here, but this was so long ago
that it is mostly lost.
What do you want to do with that info? Write your own
dpmi server?
For example he suggested to alter the exception routing
rules. While dpmi spec says unhandled exceptions 1..5 and 7
should generate real-mode interrupts, he suggested to
call the protected-mode handlers instead, and if there
are none - terminate the client, but never call the real-mode
interrupt the way spec does.
Also there are many undocumented things, for instance,
the limit of LDT selector must dynamically grow when
you allocate the descriptors in LDT.
There is a summary on undocumented DPMI:
ftp://ifctfvax.harhan.org/pub/micro/msdos/above640k/TrueDPMI/dpmiext.txt
but it documents actually nothing of what we didn't know
ourselves. The most important and difficult to discover
things are not in that doc.
After that, I did an attempt to port dosemu's PM api
translator to DOS. The idea was to make it runnable

Re: Running win.com from Chicago (alpha version of Win95)

30.05.2014 01:39, Julius Schwartzenberg пишет:
> Yes, of course. But it'd still be really cool if it could work in
> DOSEMU :)
Were you running it after booting in its own DOS?
It will not work with freedos or even MS-DOS other
than its own.
Also, are you aware about HX dos extender?
It has a win32 support built-in and works in dosemu.
Of course I admit that running a kind of win95 would
be a good demo of dosemu's abilities. :)
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/downloadhttp://p.sf.net/sfu/restlet
_______________________________________________
Dosemu-devel mailing list
Dosemu-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dosemu-devel

Running win.com from Chicago (alpha version of Win95)

Hi,
When I run win.com from Chicago in DOSEMU, I immediately get my prompt
back. It seems nothing happens then. Could it be possible that some
detection that Windows is already running is triggered and that win.com
is written to not do anything then?
Did anybody every try to run Chicago in DOSEMU?
Best regards,
Julius
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/downloadhttp://p.sf.net/sfu/restlet