Re: GSoC WPKG and test.winehq.org

2010-04-04 Thread Austin English
On Sun, Mar 28, 2010 at 12:53 PM, Seth Shelnutt wrote: > Alright after creating a few test scripts and playing around with things I > think I have finally settled on exactly what my proposal is. It is in three > parts, > > 1) Convert wpkg (or appDeploy) scripts into ahk scripts. I believe that I >

Re: Working on "DOS" VGA.

2010-04-04 Thread Roderick Colenbrander
On Sun, Apr 4, 2010 at 3:32 PM, k4king wrote: > > how seamless could the integration be made? > I've seen a number of programs (mainly installers) and also guilty of > writing a few win apps that shell out a dos call and return to continue. The command prompt in windows works similar to DOS but i

Re: Working on "DOS" VGA.

2010-04-04 Thread k4king
how seamless could the integration be made? I've seen a number of programs (mainly installers) and also guilty of writing a few win apps that shell out a dos call and return to continue. Also while wine seems to encourage a spread of apps to work, the core DosBox guys have made it clear they are o

Re: Working on "DOS" VGA.

2010-04-04 Thread Chris Robinson
On Sunday 04 April 2010 3:41:00 am Marcus Meissner wrote: > Yes, but those INT21 calls are in Win16 protected mode, not DOS real mode. > > And VXD ... I doubt anything uses it. Back in the Win95 era, I remember libnet having a DOS network driver that hooked into winsock.vxd. It allowed a DOS app

Re: Working on "DOS" VGA.

2010-04-04 Thread Marcus Meissner
On Sun, Apr 04, 2010 at 10:53:46AM +0200, Damjan Jovanovic wrote: > But Win16 applications can access DOS int 0x21 functions (below, > tested successfully on Wine and Vista), and at least some hardware > (http://www.faqs.org/faqs/windows/programming/vxd/ describes how a > Win16 application can acce

Re: Working on "DOS" VGA.

2010-04-04 Thread Damjan Jovanovic
On Sat, Apr 3, 2010 at 5:34 PM, Alexandre Julliard wrote: > Stefan Dösinger writes: > >> Am 02.04.2010 um 02:08 schrieb chris ahrendt: >> >>> Just my 2 phennings worth on this... >>> Why reinvent the wheel... I would say instead of doing the emulator inside >>> wine... or a JIT... why not have >