On Mon, Jun 14, 2004 at 03:33:52PM +0800, Yan Hao, SLC ICM N R&D TD-SCDMA (BJ) wrote:
> Dear all,
>
> I want to extend ethereal to a new protocol and run it in windows enviroment.
>
> Could you give me some suggestion if I should develop it based on Windows platform or Linux platform?
> - Is there blocking problems if I set the whole development environment on Windows?
I'm very new to ethereal development, but I faced the same situation, so I will
relate what I found.
If you have Visual C++ 6, it should not be too problematic. That's the standard
development environment for ethereal on Windows. Visual Studio .NET should work
too, perhaps with some additional effort. The licensing of ethereal and the
default VS .NET C runtime library may prohibit you from distributing binaries
you would compile (outside your organization). Since you mail from a corporate
address, I suppose you have access to one of these tools. If not, read on ...
I tried to build using Microsoft Visual C++ Toolkit 2003, a no-cost distribution
of the Microsoft compilers and binary tools. I do not recommend this. If you
would like to try, though, I can send you some nontrivial Makefile patches that
made it mostly work for me.
You can build and run ethereal under Cygwin. If you wish to do this and
actively develop a dissector, I *highly* recommend that you either (a) develop
your dissector in the form of the plugin or (b) cross-compile for Cygwin from a
Unix system. In most respects, this build process is fairly straightforward,
though you will need patches to build GTK+ 2.x and the packages on which it
depends from the official sources. I can send you some documentation with a
list of the patches if you want to do this. You can also find some older
documentation on building with GTK+ 1.2.x in README.win32. If you choose this
approach, also ensure that all packages you build use libtool >= version 1.5.
(The Unix build procedure is very slow on windows - a ``make install'', for
example, takes 10 minutes on my 666 MHz PIII, as compared to less than thirty
seconds on a 2 GHz Linux system. As I understand it, this happens because
Windows does not have a copy-on-write fork(2)-like function, so Cygwin emulates
fork(2) by copying the entire program memory image. This wrecks the performance
of tools such as ``make'', ``libtool'', and ``autoconf'' scripts, which all
spawn new processes at high rates.)
> - Is it difficult to develop on Linux and make the load for windows?
Do you ask whether it is reasonable to develop your dissector on Linux and then
transfer the code to Windows to build and run it for production use? I had no
problems doing that.
