colinux-devel — Cooperative Linux development mailing list

Re: [coLinux-devel] Help on Fedora

[Jaroslaw K. <ja...@zd...>]

I'm just uploading a package containing Fedora Core 1 root image + config
file + kernel + setup instructions.

In about 30 minutes it will be available at:

http://jaak.sav.net/colinux/

The file is about 70 MBs in size and contains a 2GB root image + bzipped
swapfiles for your convenience. Fedora is quite minimal and contains nothing
but the core packages. It has "vim" and "nano" text editors "apt-get" to
update and install new software.

I used the latest snapshot of CoLinux

http://www.colinux.org/snapshots/coLinux-20040411-2.exe)

Haven't tested it against 0.6.0.

Jarek

P.S. The bandwidth at sav.net is not infinite, so it would be great if
someone could put this on sourceforge.

----- Original Message ----- 
From: <wa...@co...>
To: <col...@li...>
Sent: Tuesday, April 13, 2004 4:48 PM
Subject: [coLinux-devel] Help on Fedora


> Is there a good resource or "how-to" on how I could use the Fedora distro
on colinux, vs. the Debian or Gentoo images that are available?
>
> Thanks!
>
> --
> Scott Ware
> wa...@co...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] documentation, icons

[tei <42...@in...>]

>>Hello,
>>
>>The doc/ directory in the source tarball needs to be updated. It would
>>very be good if one of you would take a few pages from the Wiki site, 
>>compile them into a few documents and send me a patch.
>>
>>We also need icons for the daemons / consoles executables. Would anyone 
>>with the graphics acumen like to contribute?
>>
>>-- 
>>Dan Aloni
>>da...@co...
>>
>>



Something about:

colinux-daemon.exe

My first attemp

http://telejano.berlios.de/option/colinux1.ico

Triing to make a circular version of the icon with a dirty result :/

http://telejano.berlios.de/option/colinux4.ico

The icon is derived work from this icons:
http://www.gentoo.org/dyn/icons/DES.xml
http://www.gentoo.org/images/icons/l33t_DES_grey-hdd_win_umount.png

Re: [coLinux-devel] Help on Fedora

[Robert P. <rob...@ho...>]

A while ago, someone posted here a script that sets up a FC1 installation
image file. I took it and improved it so that it will even download the RPMs
from the net and create the swap image. Here you go (in the attachment).

Thanks.

Rob

----- Original Message ----- 
From: <wa...@co...>
To: <col...@li...>
Sent: Tuesday, April 13, 2004 7:48 AM
Subject: [coLinux-devel] Help on Fedora


> Is there a good resource or "how-to" on how I could use the Fedora distro
on colinux, vs. the Debian or Gentoo images that are available?
>
> Thanks!
>
> --
> Scott Ware
> wa...@co...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

[coLinux-devel] Help on Fedora

[<wa...@co...>]

Is there a good resource or "how-to" on how I could use the Fedora distro on colinux, vs. the Debian or Gentoo images that are available?

Thanks!

--
Scott Ware
wa...@co...

Re: [coLinux-devel] documentation, icons

[Digital I. Inc. <ok...@di...>]

Okay, for an icon stuff, I will do it.
I am not so good at graphics, but I hope you like it.
of course, anyone who is talented about graphics is in this list,
please do it instead of me!.

documents? ask English native. Or you want to see my very original
and unique language which hopefully resembles to English?

               --- Okajima.

>Hello,
>
>The doc/ directory in the source tarball needs to be updated. It would
>very be good if one of you would take a few pages from the Wiki site, 
>compile them into a few documents and send me a patch.
>
>We also need icons for the daemons / consoles executables. Would anyone 
>with the graphics acumen like to contribute?
>
>-- 
>Dan Aloni
>da...@co...
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

[coLinux-devel] Why not utilize NT's Subsystem capabilities?

[Anthony S. <an...@si...>]

I think you have a great vision and a great product, but why are you using a
virtualization method for hosting the CoLinux environment on Windows instead
of creating a true Linux Subsystem?

 

Using the NT Subsystem would allow you many of the features you are striving
to implement, especially interoperability with the existing Win32 subsystem
and the NT kernel level drivers?

 

One of the remarkable abilities of the NT architecture is the client/server
kernel that allows for Subsystem implementations, as has been demonstrated
by Win32, Win64, OS/2, Posix, and even Microsoft Unix services. They are all
basic independent OSes with their own kernels that sit on top of the NT
kernel architecture.

 

If you designed CoLinux as a true subsystem of NT, you would still be able
to maintain a full Linux kernel and binary compatibility, but also be able
to utilize drivers from the NT core and not have to virtualize 'host
drivers' and also be able to share information via the NT kernel to other
subsystems like Win32/Win64, etc.

 

Even XWindowed applications could run in independent windows and not in the
CoLinux virtualization Window.

 

I don't know if this is a concept you have already explored, but I find it
strange that with the NT kernel subsystem technologies that you would set
out to create a virtualization environment for your CoLinux instead of
creating an NT Linux Subsystem.

 

Keep up the good work,

Anthony

Re: [coLinux-devel] Slashdot mention of CoLinux + review at Linuxworld

[Eric S. J. <es...@ha...>]

Richard Goodwin wrote:
> http://www.linuxworld.com/story/44466.htm
> 
> Here come the crowds, round 2 :-)
> 
> http://slashdot.org/
> 

http://www.haaretzdaily.com/hasen/spages/414290.html

missed one.

[coLinux-devel] Slashdot mention of CoLinux + review at Linuxworld

[Richard G. <ric...@ri...>]

http://www.linuxworld.com/story/44466.htm

Here come the crowds, round 2 :-)

http://slashdot.org/

[coLinux-devel] connection trapper

[peter g. <plu...@p1...>]

just a quick status update on my connection trapper

currently i am using a tcp connection over an existing lan for guest->host
connection while i admit this defeats the object it is allowing me to test
the code while waiting for coserial which should provide the final method of
linking

note: stuff that doesn't use tcp or udp for example ping and traceroute will
never work on this setup

here are the planned features

outgoing tcp connections: transparent tcp level proxying

outgoing udp connections: full cone nat (see
http://www.faqs.org/rfcs/rfc3489.html for the definition of full cone)

connenection to host: any connections made to ips in the block 192.0.2.0/24
will make a connection on the host side to the corresponding ips in the
block 127.0.0.0/24

and here is the status

tcp trapping: works fine and i have even run X over it while testing with no
noticeable lag

udp trapping: i can catch udp packets and determine thier original source
port destination ip and destination port and i can send udp packets with any
combination of source and destination ips/ports i like but i still need to
write the actual nat code

special target ips: work perfectly
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 31/03/2004

Re: [coLinux-devel] Fedora core kernel

[Robert P. <rob...@ho...>]

Daniel

I tried your kernel. It works with FC1 DHCP using dhclient. Thanks a =
lot! I will be great that the next coLinux kernel build will also =
include socket filtering for those of us who use FC and DHCP.

Rob=20
  ----- Original Message -----=20
  From: Daniel Slater=20
  To: col...@li...=20
  Sent: Friday, April 09, 2004 9:54 AM
  Subject: [coLinux-devel] Fedora core kernel


  For those of you who are trying to get DHCP working for FC1, here is =
my kernel image and modules. =
http://www.geocities.com/dan_slater/colinux/fedora.tar.gz This kernel =
has socket filtering turned on for DHCP. It also has most of the network =
file systems ( including smbfs ) enabled as modules. I have been using =
this kernel to run my dual-boot FC1 installation under colinux. Hope you =
find it useful.

  =20

  Dan

  =20

[coLinux-devel] Re: Mingw patch for CoLinux console/deamon

[Dan A. <da...@co...>]

On Mon, Apr 12, 2004 at 07:43:24AM -0700, Steven Edwards wrote:
> Hi Dan,
> 
> --- Dan Aloni <da...@co...> wrote:
> > Anyway, as from the 20040411 snapshot, the daemon and console-nt
> > don't 
> > depend on Cygwin, so you can test console-nt to see if it works on
> > ReactOS.
> > 
> > > 2. The user has to go download/install the mxml sources for the
> > > mingw-crosscompiler. Once again its small we could ship this with
> > the
> > > coLinux sources.
> > 
> 
> Cool. I sent test binarys to most of the ReactOS developers that are
> interested in this when I did my port to mingw. Currently we are
> debugging some issues in our named pipes and service control manager
> implemenation. Once this is done CoLinux should just "work". I tested
> loading linux.sys standalone as a boot driver and ReactOS is able to do
> this with no issue so once we have the SCM/Pipe issues worked out I
> thnk we should be able to load vmlinux. I have sent a copy of this
> message to ros-kernel to try and get a few more developers interested
> in kicking out the SCM/Pipe issues.

It's nice to see that coLinux helps to bring ReactOS to completeness.

It will be good if some of the ReactOS developers, especially the kernel 
hackers, could look at the kernel driver's sources and pin-point about 
specific problems. As you may know, we have problems in the SMP area.

    http://www.colinux.org/snapshots

The winnt-dependent kernel code is under src/colinux/os/winnt/kernel,
whereas the os-independent kernel mode is under src/colinux/kernel and
src/colinux/arch.

> > > 5. It links to ws2_32 but I have not tested the networking stuff so
> > we
> > > will have to adapt the rest to use use Winsock but it will still be
> > > faster than using Cygwin->Winsock.
> > 
> > That networking code in the daemon is not that important (used for 
> > debugging).
> 
> who needs a debugger anyway...It may still be a while for ReactOS to
> really show use to the CoLinux team as our networking still has large
> spots that are not connected. Its my hope that in the next few months
> we can plug those holes so that any Linux user that need a Windows
> driver can deploy ReactOS with CoLinux running on top.

Cool. Have you managed to build coLinux using the latest snapshot and
the bunch of scripts I posted?

-- 
Dan Aloni
da...@co...

Re: RE : [coLinux-devel] SMP system freeze completely

[Dan A. <da...@co...>]

On Mon, Apr 12, 2004 at 11:55:36AM -0400, Clemmitt M. Sigler wrote:
> Hi,
> 
> On Fri, 2 Apr 2004, Florent CUETO wrote:
> > I have applied the imagecfg patch on the executables, now colinux works
> > perfectly on my P4 3.0C HT.
> > Like Alejandro, I've patched all .exe (I did not try to apply the patch
> > on colinux-deamon only).
> 
> [..snips..]
> 
> Case E is interesting.  Running either c-n-d or c-c-f as an MP
> .exe seems to boot OK, but running them *both* as MP .exe's caused
> boots/shutdowns to hang after a few tries.

Your test cases are interesting. The one that I find most bizarre is the
C case. It's the only case that involves a daemon communicating with a 
kernel driver (this case, the TAP driver), whose executable is not marked
UP *and* it doesn't incur hangs. The only diff between C and E is only the UP
flag of the FLTK console, and it's weird that only that change causes 
hangs, as the FLTK console process doesn't communicate with any driver.

Please test it without networking at all, so in case where the TAP 
driver is faulty on SMP, it doesn't gets in our way when we try to find 
the problem with coLinux.

-- 
Dan Aloni
da...@co...

Re: RE : [coLinux-devel] SMP system freeze completely

[Clemmitt M. S. <sig...@bl...>]

Hi,

On Fri, 2 Apr 2004, Florent CUETO wrote:
> I have applied the imagecfg patch on the executables, now colinux works
> perfectly on my P4 3.0C HT.
> Like Alejandro, I've patched all .exe (I did not try to apply the patch
> on colinux-deamon only).

Quick summary: I don't see stability problems with coLinux once
it's running, but I do see cL hangs on startup or shutdown which
cause the Windows host OS to stop working then hang.  I experimented
with configuring some of the executables for uniprocessor
operation via imagecfg -u and got some interesting results.  Some
combinations boot/shutdown without hanging, others hang with
regularity.

Long version: I finally had time to experiment with coLinux-0.6.0 on my 
ancient SMP server box at home.  It's an Intel N440BX machine with dual 
PIII 600 CPUs and 768MB of RAM.  My host OS is WinXP Pro with SP1a and 
all the latest critical and driver updates installed.  I did this using
the Red Hat 9 image with wget, openssh-clients, and samba-clients 
installed, and using 64MB of RAM and a 256MB swap device.  The network
was configured for "tap" access with Internet Connection Sharing
under Windows.

I stress-tested coLinux by running two network and one number-crunching
tests.  The network tests were down/uploading linux-2.6.5.tar.bz2 and
patch-2.6.5.bz2 on my outside DSL connection using wget and scp, and
put/getting the same files to/from the host OS using smbclient.  The
number-crunching program was a small threaded program to calculate
the digits of pi to arbitrary precision.  I ran the network and
number-crunching tests for approx. 2 1/2 hrs. each to see if I
could find any instability.  Under all cases (*.exe being configured
for either UP or MP) coLinux running the Red Hat image didn't
crash or hang.  I didn't try running two tests simultaneously so
maybe I'm not stressing it hard enough.

However, I still see boot/shutdown hangs when running the
original executables on the SMP box.  So I set up some of the
executables to be uniprocessor via imagecfg -u.  Here are
my results (I didn't test colinux-console-nt or 
colinux-bridged-net-daemon):

-------------------------------------------------------------------------
Test case   |   c-d   |   c-n-d   |   c-c-f   |   Result
-------------------------------------------------------------------------
    A       |    U    |     U     |     U     | No hangs seen
-------------------------------------------------------------------------
    B       |         |     U     |     U     | Hangs within a few boots
-------------------------------------------------------------------------
    C       |    U    |           |     U     | No hangs seen
-------------------------------------------------------------------------
    D       |    U    |     U     |           | Ho hangs seen
-------------------------------------------------------------------------
    E       |    U    |           |           | Hangs within a few boots
-------------------------------------------------------------------------
Key:
     " " == Run as original multiprocessor executable
     "U" == Run as uniprocessor executable after `imagecfg -u'
     "c-d" == colinux-daemon.exe
     "c-n-d" == colinux-net-daemon.exe
     "c-c-f" == colinux-console-fltk.exe
     "No hangs seen" == Booted/shutdown 6 times consecutively without
                        a hang seen
     "Hangs within a few boots" == Hangs within 1-3 consecutive
                                   boots/shutdowns

Once case B boots, it seems to run fine.  I couldn't induce any crashes 
or hangs while running my network or computational stress-testing,
but maybe I'm not testing rigorously enough?

Case E is interesting.  Running either c-n-d or c-c-f as an MP
.exe seems to boot OK, but running them *both* as MP .exe's caused
boots/shutdowns to hang after a few tries.

Again, this is just my own config and testing at home, YMMV :^)

					Clemmitt

[coLinux-devel] Re: Mingw patch for CoLinux console/deamon

[Steven E. <ste...@ya...>]

Hi Dan,

--- Dan Aloni <da...@co...> wrote:
> Anyway, as from the 20040411 snapshot, the daemon and console-nt
> don't 
> depend on Cygwin, so you can test console-nt to see if it works on
> ReactOS.
> 
> > 2. The user has to go download/install the mxml sources for the
> > mingw-crosscompiler. Once again its small we could ship this with
> the
> > coLinux sources.
> 

Cool. I sent test binarys to most of the ReactOS developers that are
interested in this when I did my port to mingw. Currently we are
debugging some issues in our named pipes and service control manager
implemenation. Once this is done CoLinux should just "work". I tested
loading linux.sys standalone as a boot driver and ReactOS is able to do
this with no issue so once we have the SCM/Pipe issues worked out I
thnk we should be able to load vmlinux. I have sent a copy of this
message to ros-kernel to try and get a few more developers interested
in kicking out the SCM/Pipe issues.
 
> > 5. It links to ws2_32 but I have not tested the networking stuff so
> we
> > will have to adapt the rest to use use Winsock but it will still be
> > faster than using Cygwin->Winsock.
> 
> That networking code in the daemon is not that important (used for 
> debugging).

who needs a debugger anyway...It may still be a while for ReactOS to
really show use to the CoLinux team as our networking still has large
spots that are not connected. Its my hope that in the next few months
we can plug those holes so that any Linux user that need a Windows
driver can deploy ReactOS with CoLinux running on top.

Thanks
Steven


__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

Re: [coLinux-devel] Cygwin dependency removed

[Dan A. <da...@co...>]

On Mon, Apr 12, 2004 at 10:07:44AM -0000, Thomas Fritzsche wrote:

> this sounds really cool and should make the build process more clean. I
> would like to update the cobuild.sh, but because I'm currently in easter
> holidays, this is not possible before next weekend. So if this is a matter
> of time someone else should jump in.
> 
> Just a question about cross-build.sh . Is this script you posted a
> modified version from cross-build.sh from this site:
> 
> http://basic.mozillanews.org/clanlib/mingw.html
> http://www.libsdl.org/extras/win32/cross/cross-configure.sh (original?)

Yes, I posted a modified version of the script.

If you are going to update cobuild.sh, you should base your efforts 
on what I have attached to this mail. I've splitted cross-build.sh and
enhanced it so it would patch w32api-2.5, and also download and build 
FLTK and mxml for the mingw32 environment. This tarball is the exact
files from my current version of the coLinux tree.

I also noticed that pcap is also easy to install. Just get taking out 
the right files from wpdpack_3_0.zip and putting them in the mingw32 
tree.

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] Cygwin dependency removed

[Thomas F. <tf...@no...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Dan,

this sounds really cool and should make the build process more clean. I
would like to update the cobuild.sh, but because I'm currently in easter
holidays, this is not possible before next weekend. So if this is a matter
of time someone else should jump in.

Just a question about cross-build.sh . Is this script you posted a
modified version from cross-build.sh from this site:

http://basic.mozillanews.org/clanlib/mingw.html
http://www.libsdl.org/extras/win32/cross/cross-configure.sh (original?)

Thanks and regards,
 Thomas


> Hello,
>
> I have uploaded a snapshot completely independent of Cygwin.
>
> It doesn't yet include an updated version of cobuild.sh (a fixed
> version should be based on the cross-build.sh that I posted earlier).
>
> --
> Dan Aloni
> da...@co...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAempwnwJBIFTVIqwRAgVDAJ0ax1YjLkOZhroTreDx0uXiaQcaSACdEud2
ia74eNgida0iL2ZJrhlJUZ8=
=of1G
-----END PGP SIGNATURE-----

Re: [coLinux-devel] Re: Mingw patch for CoLinux console/deamon

[Dan A. <da...@co...>]

On Sun, Apr 11, 2004 at 01:41:48PM -0700, Steven Edwards wrote:

> --- Dan Aloni <da...@co...> wrote:
> > Okay, I managed to port the build-cross.sh script to the latest
> > stable 
> > versions of the tools. The only difference is that it requires the
> > files 
> > to be downloaded.
> 
> One thing I didnt think about was that on cygwin you can force linking
> to msvcrt by passing the -mno-cygwin flag to gcc. Could you try
> building a Colinux install with it? If this is the case then we might
> still be able to use FLTK and keep the cygwin setup. 

No need, FLTK works with the MingW32 setup.

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] Re: Mingw patch for CoLinux console/deamon

[Steven E. <ste...@ya...>]

Hi Dan,

--- Dan Aloni <da...@co...> wrote:
> Okay, I managed to port the build-cross.sh script to the latest
> stable 
> versions of the tools. The only difference is that it requires the
> files 
> to be downloaded.

One thing I didnt think about was that on cygwin you can force linking
to msvcrt by passing the -mno-cygwin flag to gcc. Could you try
building a Colinux install with it? If this is the case then we might
still be able to use FLTK and keep the cygwin setup. 

Thanks
Steven


__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

[coLinux-devel] cobd* size problems

[Ronald P. <pij...@ds...>]

Hi,

To resolve the codb* size problems, is it possible to isolate the code
that accesses the partition (with the driver code to go with that)?

That should help putting a finger on it.

Ronald.

[coLinux-devel] coserial driver

[peter g. <plu...@p1...>]

s0be was saying on irc that he had a coserial driver that just about worked

if this is the case s0be can you please send me it along with instructions
for use

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 31/03/2004

[coLinux-devel] documentation, icons

[Dan A. <da...@co...>]

Hello,

The doc/ directory in the source tarball needs to be updated. It would
very be good if one of you would take a few pages from the Wiki site, 
compile them into a few documents and send me a patch.

We also need icons for the daemons / consoles executables. Would anyone 
with the graphics acumen like to contribute?

-- 
Dan Aloni
da...@co...

[coLinux-devel] Cygwin dependency removed

[Dan A. <da...@co...>]

Hello,

I have uploaded a snapshot completely independent of Cygwin. 

It doesn't yet include an updated version of cobuild.sh (a fixed 
version should be based on the cross-build.sh that I posted earlier).

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] Re: Mingw patch for CoLinux console/deamon

[Dan A. <da...@co...>]

On Sun, Apr 11, 2004 at 01:06:04AM +0300, Dan Aloni wrote:
> On Fri, Apr 09, 2004 at 02:46:20PM -0700, Steven Edwards wrote:
> > Hello All,
> > Well here it is in all of its glory. All 5 lines of it. It works but we
> > (ReactOS team) have not tested it beyond booting the kernel.
> 
> So the kernel really booted. Can you post a screenshot?
> 
> > There are a few changes that will need to be made before this can be
> > merged in and we can drop Cygwin I guess. But I beg and plead that we
> > do this so we can drop Cygwin totaly if we are not going to need it for
> > the Xserver.
> 
> I agree, Cygwin should be dropped.
> 
> > 1. The FLTK console wont build on the Mingw cross-compiler as we lack
> > support for it. I guess we could ship our own copy.
> 
> I got it built using the Mingw cross compiler, but I couldn't test the 
> library because of some linkage problems.
> 
> I've fiddled a few hours with creating a i686-pc-mingw32 cross compiler, 
> and found a bunch of annoying problems with gcc's build - actual build 
> system bugs. Do you have scripts that automatically create a mingw32 
> cross compilation toolkit on Linux using recent versions of gcc 
> and binutils? What versions do you use? I'd really benefit from it.

Okay, I managed to port the build-cross.sh script to the latest stable 
versions of the tools. The only difference is that it requires the files 
to be downloaded.

-rw-------    1 karrde   karrde   14182109 Apr 10 20:55 binutils-2.15.90-20040222-1-src.tar.gz
-rw-------    1 karrde   karrde   13268861 Apr 11 09:17 gcc-core-3.3.1-20030804-1-src.tar.gz
-rw-------    1 karrde   karrde    2723676 Apr 11 09:11 gcc-g++-3.3.1-20030804-1-src.tar.gz
-rw-------    1 karrde   karrde     308420 Apr 10 21:09 mingw-runtime-3.2.tar.gz
-rw-------    1 karrde   karrde    1336713 Apr 10 21:12 w32api-2.5.tar.gz

[10:49 pts/424,callisto source]% i686-pc-mingw32-gcc -v

Reading specs from /usr/local/mingw32/lib/gcc-lib/i686-pc-mingw32/3.3.1/specs
Configured with: /home/karrde/colinux/res/mingw32/cross/source/gcc-3.3.1-20030804-1/configure -v --prefix=/usr/local/mingw32 --target=i686-pc-mingw32 --with-headers=/usr/local/mingw32/i686-pc-mingw32/include --with-gnu-as --with-gnu-ld --without-newlib --disable-multilib
Thread model: single
gcc version 3.3.1 (mingw special 20030804-1)

I didn't try to build coLinux with it yet. There will be more to follow.

-- 
Dan Aloni
da...@co...

[coLinux-devel] Re: Mingw patch for CoLinux console/deamon

[Dan A. <da...@co...>]

On Fri, Apr 09, 2004 at 02:46:20PM -0700, Steven Edwards wrote:
> Hello All,
> Well here it is in all of its glory. All 5 lines of it. It works but we
> (ReactOS team) have not tested it beyond booting the kernel.

So the kernel really booted. Can you post a screenshot?

> There are a few changes that will need to be made before this can be
> merged in and we can drop Cygwin I guess. But I beg and plead that we
> do this so we can drop Cygwin totaly if we are not going to need it for
> the Xserver.

I agree, Cygwin should be dropped.

> 1. The FLTK console wont build on the Mingw cross-compiler as we lack
> support for it. I guess we could ship our own copy.

I got it built using the Mingw cross compiler, but I couldn't test the 
library because of some linkage problems.

I've fiddled a few hours with creating a i686-pc-mingw32 cross compiler, 
and found a bunch of annoying problems with gcc's build - actual build 
system bugs. Do you have scripts that automatically create a mingw32 
cross compilation toolkit on Linux using recent versions of gcc 
and binutils? What versions do you use? I'd really benefit from it.

I also tried to use the -mno-cygwin gcc flag. It worked for the daemon, 
but then I found out that libstdc++ depends on a symbol inside cygwin1.dll! 
So I had to specially compile a new libstdc++ that doesn't refer that 
symbol (___getreent. I had to use --disable-threads and pull more defines 
from the hat to get it working).

Anyway, as from the 20040411 snapshot, the daemon and console-nt don't 
depend on Cygwin, so you can test console-nt to see if it works on
ReactOS.

> 2. The user has to go download/install the mxml sources for the
> mingw-crosscompiler. Once again its small we could ship this with the
> coLinux sources.

Or we could ship a patch for it.

> 3. You need to change i*86-cygwin-blah to -*86-mingw32-blah for all of
> the commands in your makefile to support a mingw cross

It only needs to be changed in one location.

> 4. We need to add some configure like checking for these headers I have
> added the ifdefs for in this patch.
> 
> 5. It links to ws2_32 but I have not tested the networking stuff so we
> will have to adapt the rest to use use Winsock but it will still be
> faster than using Cygwin->Winsock.

That networking code in the daemon is not that important (used for 
debugging).

-- 
Dan Aloni
da...@co...

[coLinux-devel] CoLinux file utilities

[Daniel S. <dan...@au...>]

I have posted updated versions of my file utilities for CoLinux. I have
also added an entry to the Nice Tool Wiki Page
<http://www.colinux.org/wiki/index.php/NiceTools>
http://www.colinux.org/wiki/index.php/NiceTools describing how to use
them. The sources are at
http://www.geocities.com/dan_slater/colinux/file-utils.tgz Pre-compiled
binaries for MinGW and Cygwin at
http://www.geocities.com/dan_slater/colinux/file-utils-mingw-bin.tgz and
http://www.geocities.com/dan_slater/colinux/file-utils-cygwin-bin.tgz

=20

I hope you find these useful.

=20

=20