> ack can run on the x86/Windows,
> SQLite has been or will be ported to minix3?

Take a look here : http://www.minix3.org/software/
I've found ACK and SQLite

Good look,

On Jul 18, 3:14 pm, Benny wrote:
> > ack can run on the x86/Windows,
> > SQLite has been or will be ported to minix3?
>
> Take a look here :http://www.minix3.org/software/
> I've found ACK and SQLite
>
> Good look,

thanks for your help.

On Jul 20, 8:24 am, fp_gz wrote:
> On Jul 18, 3:14 pm, Benny wrote:
>
> > > ack can run on the x86/Windows,
> > > SQLite has been or will be ported to minix3?
>
> > Take a look here :http://www.minix3.org/software/
> > I've found ACK and SQLite
>
> > Good look,
>
> thanks for your help.

This version of ack runs on the minix3. I wish to know whether it can
run on MS windows. I have heard ack has a platform-indepedent
version.
thanks

> This version of ack runs on the minix3. I wish to know whether it can
> run on MS windows. I have heard ack has a platform-indepedent
> version.

These seem to be the webistes for different versions of ACK.
http://tack.sourceforge.net/
http://www.cs.vu.nl/ack/

They mention ACK being able to run on "any decent UNIX system". You
could try compiling it in Cygwin if you want it on Windows, but you
probably wouldn't be able to generate the PE binaries Windows wants.

On Jul 20, 2:32 pm, "Erik van der Kouwe" wrote:
> > This version of ack runs on the minix3. I wish to know whether it can
> > run on MS windows. I have heard ack has a platform-indepedent
> > version.
>
> These seem to be the webistes for different versions of ACK.http://tack.sourceforge.net/http://www.cs.vu.nl/ack/
>
> They mention ACK being able to run on "any decent UNIX system". You
> could try compiling it in Cygwin if you want it on Windows, but you
> probably wouldn't be able to generate the PE binaries Windows wants.


thanks.
ack just works as gcc for Cygwin . But i know someone make the gcc a
windows .exe file. do anyone know it is how hard to make ack a
windows .exe file?

> ack just works as gcc for Cygwin . But i know someone make the gcc a
> windows .exe file. do anyone know it is how hard to make ack a
> windows .exe file?

I'm not sure but I think a.out is the trick. Take a look here :
http://fxr.watson.org/fxr/source/boo...?v=minix-3-1-1

Hope this helps a little,

fp_gz wrote:

> On Jul 20, 2:32 pm, "Erik van der Kouwe" wrote:
> > > This version of ack runs on the minix3. I wish to know whether
> > > it can run on MS windows. I have heard ack has a
> > > platform-indepedent version.
> >
> > These seem to be the webistes for different versions of
> > ACK.http://tack.sourceforge.net/http://www.cs.vu.nl/ack/
> >
> > They mention ACK being able to run on "any decent UNIX system". You
> > could try compiling it in Cygwin if you want it on Windows, but you
> > probably wouldn't be able to generate the PE binaries Windows wants.
>
>
> thanks.
> ack just works as gcc for Cygwin . But i know someone make the gcc a
> windows .exe file. do anyone know it is how hard to make ack a
> windows .exe file?

Windows is not listed as a supported platform, so ACK will probably not
be able to produce the PE exe files Windows wants. This means you'd
have to compile ACK itself using another compiler, such as GCC.

I don't think just converting an a.out file to a COM file would work.
The former uses the Minix system call interface, while the latter would
have to use the MS-DOS system call interface. The a.out file would also
have to be 16 bit, as COM files are always executed in 16 bit MS-DOS
emulation and AFAIK it cannot be larger than 65536 bytes.

>> thanks.
>> ack just works as gcc for Cygwin . But i know someone make the gcc a
>> windows .exe file. do anyone know it is how hard to make ack a
>> windows .exe file?
>
> Windows is not listed as a supported platform, so ACK will probably not
> be able to produce the PE exe files Windows wants. This means you'd
> have to compile ACK itself using another compiler, such as GCC.
>
> I don't think just converting an a.out file to a COM file would work.
> The former uses the Minix system call interface, while the latter would
> have to use the MS-DOS system call interface. The a.out file would also
> have to be 16 bit, as COM files are always executed in 16 bit MS-DOS
> emulation and AFAIK it cannot be larger than 65536 bytes.

I agree that it is probably not worth the trouble: There is already a
plethora of windows C compilers around:

- free as in beer Borland C++
- lcc (free for non commercial use AFAIR)
- MingW gcc
- WatCom C/C++ (free in the open source sense, I think)

I doubt ACK (which has a very simple backend WRT optimization) will
produce executables that can compete.

But:

> I don't think just converting an a.out file to a COM file would work.
> The former uses the Minix system call interface, while the latter would
> have to use the MS-DOS system call interface. The a.out file would also

... this is a question of the libraries / compiler run time. The
compiler should not produce system calls in the object files (or
AFAICS anything system specific).

Regards -- Markus

> > I don't think just converting an a.out file to a COM file would
> > work. The former uses the Minix system call interface, while the
> > latter would have to use the MS-DOS system call interface. The
> > a.out file would also
>
> .. this is a question of the libraries / compiler run time. The
> compiler should not produce system calls in the object files (or
> AFAICS anything system specific).

Sure, but as there is no Windows version of ACK, the libraries that
come with it will also not use Windows calls, but rather Linux, Minix,
or whatever platform those libraries were intended for.

As a.out supports no dynamic linking (and neither does COM btw) these
libraries are embedded in the a.out file and will also end up in the
COM file. It will then call the Linux/Minix/whatever interrupt vectors
rather than the MS-DOS ones, so it won't work.

On Jul 24, 3:19 am, "Erik van der Kouwe" wrote:
> > > I don't think just converting an a.out file to a COM file would
> > > work. The former uses the Minix system call interface, while the
> > > latter would have to use the MS-DOS system call interface. The
> > > a.out file would also
>
> > .. this is a question of the libraries / compiler run time. The
> > compiler should not produce system calls in the object files (or
> > AFAICS anything system specific).
>
> Sure, but as there is no Windows version of ACK, the libraries that
> come with it will also not use Windows calls, but rather Linux, Minix,
> or whatever platform those libraries were intended for.
>
> As a.out supports no dynamic linking (and neither does COM btw) these
> libraries are embedded in the a.out file and will also end up in the
> COM file. It will then call the Linux/Minix/whatever interrupt vectors
> rather than the MS-DOS ones, so it won't work.

I know the Cygwin enulate the POSIX system call.
I do not know how ack is implemented and whether it use the Posix
call. Which it is easier for rewriteing the ack by dos call and for
using dos call emulating Posix call?
thanks

> > Sure, but as there is no Windows version of ACK, the libraries that
> > come with it will also not use Windows calls, but rather Linux,
> > Minix, or whatever platform those libraries were intended for.
> >
> > As a.out supports no dynamic linking (and neither does COM btw)
> > these libraries are embedded in the a.out file and will also end up
> > in the COM file. It will then call the Linux/Minix/whatever
> > interrupt vectors rather than the MS-DOS ones, so it won't work.
>
> I know the Cygwin enulate the POSIX system call.
> I do not know how ack is implemented and whether it use the Posix
> call. Which it is easier for rewriteing the ack by dos call and for
> using dos call emulating Posix call?

AFAIK Cygwin doesn't really emulate POSIX system calls, but links to
DLLs to provide the POSIX interface. This means executables are never
binary compatible, and must be recompiled. So, to get ACK to work on
Windows, you would have to compile it on another compiler (such as GCC)
first.