From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8e03800a4e1267b281b551eed76019f6@quintile.net>
From: "Steve Simon" <steve@quintile.net>
Date: Thu, 28 Jul 2016 11:49:14 +0100
To: 9fans@9fans.net
In-Reply-To: <052AE7BC-8AD5-4C0D-9E7A-F67F9B02905C@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Any demand for a supported Windows version of p9port?
Topicbox-Message-UUID: 96b0ae78-ead9-11e9-9d60-3106f5b1d025

I have a different approach.

Personally I have only command line utilities as I keep Plan9 as my desktop (raspberry PI).

I need to cross compile on windows so I have a tool to cpu into a windows box (called dos).
This allows me to have a rio window onto a a dos shell.

It does the trick like cpu(1) to allow me to hop from a plan9 rc(1) session (in a cifs
mounted directory on the windows box), into an rc(1) session on windows and arrive at the same
directory.

I use 'local 9fs billy' at startup to make sure sam, rio, and all windows can see my windows box,
thus plumb on windows "just works" to edit files.

e.g.

My windows box is called billy (after mr gates) and my plan9 one is custard (nice with raspberry pies).

	custard%
	custard% cat /dev/osversion ; echo
	2000
	custard% pwd
	/n/billy/c/New/Application
	custard% dos
	billy%  mswin/osversion
	Windows 7
	billy% pwd
	c:/New/Application
	billy%
	billy% make
	mingw32-make -s - -C Debug Application.elf
	billy%

I could port gmake and the gcc cross compiler to plan9 to do this but there would always be
bits missing and I need to be sure that what I check in can be built by other people working
on windows.

It compiles under mingw32 - I started a mingw64 version but never finished the work (sorry).
The port predates 9pf, I would probably have used that if I had existed. It also contains none
of the graphics code that 9pf has, so no native windows sam; though I have no need of it in my
environment.

This is all available if anyone wants it.

-Steve