Re: How to set breakpoints before mainCRTStartup?

[Steve Coleman]

Dalibor Topic wrote:

Dalibor Topic wrote:

Hi all,

in my attempts to fix an ugly bug in kaffe on Cygwin, the bug I'm 
trying to squish turned out to be triggered by something that happens 
*before* main is called.



Since I'd like to know what modifes that opcode, I hope to be able to 
set a breakpoint in gdb on the code that is executed before main in 
Cygwin.

Try running gdb with the "-command=" option and put a line in 
it like "br myfunc". I have not tried this with cygwin gdb but it works 
for me on several other OS's i use.

Any idea how to do that, i.e. where to put the breakpoint? Are there 
some docs on what happends before main() on cygwin that I could look 
up for reference while trying to hunt down this bug?


It turns out that the bug happens even before mainCRTStartup.

Has anyone seen something like that before?
I have seen something like this before. If it is a C++ app then it may 
be a constructor in a statically or golbally declared object instance. 
The compiler should generate code to call all the global object 
constructors for initializing these objects *before* calling main().

Hope this helps.

Steve.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Q: ACE library for cygwin?

[Steve Coleman]

Heiko Nardmann wrote:

Did anyone build the ACE library for Cygwin already?
 

The offical ACE take on cygwin is that it has been ported but is 
currently unsupported. My understanding is that it can be done in MinGW 
mode using cygwin tools as the build environment.

See:
http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-INSTALL.html#mingw


Also, the ACE autoconf project is working on 'configure' build support 
for cygwin though it is unclear to me just how far this goes towards 
building a pure cygwin version. Check the ACE project file 
include/makeinclude/platform_cygwin32.GNU for details.

Ref: http://www.cs.wustl.edu/~othman/aceconf/faq.htm
"
Will Win32 platforms be supported by the Autoconf integration?
   The ACE Autoconf integration will not support Win32 platforms since
   Win32 platforms generally do not have a UNIX-like environment in
   which the configure script can run, for example a Bourne shell. 
   However, the GNU-Win32  effort
   may allow the ACE Autoconf integration to work on Win32 platforms. 
   Work has been started to allow the ACE Autoconf integrations to work
   on Win32 platforms via Cygwin32.  This work is still incomplete,
   however.

"
btw - I'd be interested in knowing how things go if you do make it work.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: linux/*.h include files

[Steve Coleman]

Flavio Rabello de Souza wrote:

But i still getting an error :(

Looks like its not completelly implements the linux/if_ether.h and 
linux/in.h :)

the error message i got:

$ gcc -o sniffer sniffer.c
sniffer.c: In function `main':
sniffer.c:14: error: `PF_PACKET' undeclared (first use in this function)
sniffer.c:14: error: (Each undeclared identifier is reported only once
sniffer.c:14: error: for each function it appears in.)
sniffer.c:15: error: `ETH_P_IP' undeclared (first use in this function)
do you have any suggestion?
Well you have not given enough information for us to guess what you are 
doing, and it's probably a little off topic here, but I'll try anyway... ;-)

First I will say that I am not an expert in using raw sockets so I can 
not help you very much beyond this point with finding the definitions 
you need on cygwin, unless I find a little extra spare time on my hands 
(lol). But, if you are trying to compile the same "sniffer.c" program 
that I located on the web, which btw *IS* linux specific such as your 
errors indicate, then I would have to suggest that instead you look into 
using the libpcap library (for windows libwpcap 
http://winpcap.polito.it/default.htm). It impliments most of  the 
functionality of raw sockets, and then some! It is designed for network 
diagnostics and security monitoring in mind, and it's supposed to be 
portable as well. If you are just trying to learn about networks and 
security it will be time well invested.

http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/README.Win32?rev=1.1
http://www.mail-archive.com/cgi-bin/htsearch?restrict=;exclude=;config=winpcap-users_winpcap_polito_it;method=and;format=short;words=cygwin;page=2
There are many Unix/Windows networking and security applications that 
use this library. Personally I just use windump from the cygwin command 
line, or ethereal via a windows gui. Windump is not a "cygwin" 
application. A little time invested in learning it may help you design 
your network applications faster, more portable, and more robust. Just 
do a quick google for libpcap and see for yourself! And while you are at 
it, google for libwpcap, which is the windows version.

I hope this helps.

Steve.







--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: linux/*.h include files

[Steve Coleman]

Flavio Rabello de Souza wrote:

I´m trying to compile a C program under cygwin but it uses some linux 
include files. (#include  and #include )
On my cygwin system I have both  and  . These 
are the 'standard' includes that they probably should have used if they 
wanted their code to be portable. Try them and see if that helps. These 
standard include files will usually in turn include the 'platform 
specific' header files for that system. It is best to never use the 
'platform specific' version (e.g. linux/*.h, cygwin/*.h ) directly 
unless it is in code which would never compile and run on any other system.

Steve.







--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 'dig', 'nslookup' etc?

[Steve Coleman]

Igor Pechtchanski wrote:

There must be something wrong with your system, 
 

Yes, indeed there is! I checked it out on my machine here at work and it 
does work fine. It would not be the first time my box at home made me 
look/sound stupid on this list - lol. When its not completely catatonic 
it's usually giving me grief... Right now I'm not sure if my box or 
myself is more unstable; It's time for an upgrade for one of us I 
guess... come here HAL... now hold still... this won't hurt much...

Sorry, it's been a long week for me.  8*]



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 'dig', 'nslookup' etc?

[Steve Coleman]

Brian Dessent wrote:

You can use the binaries from the precompiled win32 BIND packages from
ISC.  They're not cygwin aware, but since they're ports from a unix-like
environment you can hardly tell the difference.
 

For the client side command line there is also 
"/cygdrive/C/WINNT/system32/NSLOOKUP.EXE" on some Win32 OS's but because 
it is not Cygwin aware you can not use it in a pipe, popen, perl 
open(X,"cmd |"), or by greping the stdout for the desired patterns 
within a script. I hve been looking for something to do a little 
scripting of my custom dynamic DNS updates at home and found the perl 
Net::DNS package yesterday, but alas, installing via CPAN.pm it failed 
some of its tests. I'll have to look into this package a little more 
when I have the time.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: perl -MCPAN -e shell crashes w98se

[Steve Coleman]

Graham Lamont wrote:

perl -MCPAN -e shell

Anybody experience similar ?
 

I've been having problems with the latest version of Perl (5.8.0-3) 
while running/installing from CPAN on WinME. Using the previous version 
(5.6.1-2) seems to work fine for me when installing from CPAN. I'm not 
sure about what is causing your problems but mine were from dll's having 
errors, and 'rebaseall' did not seem to help any. I just reverted to the 
older version until someone can figure this out or a new version comes 
out with the 64 bit stuff. If I find the time I will try building perl 
myself and look into this further, unfortunately my WinME system is 
'remote' and one 'hang' means try again tomorrow

You can message me off line if there are any specific questions on this.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: GPL alert ? http://thinstall.com/unix_tools/

[Steve Coleman]

Christopher Faylor wrote:

On Mon, Jul 28, 2003 at 07:52:36AM -0400, [EMAIL PROTECTED] wrote:
 

Not only that, but this appears to go even further.  By essentially
"compiling" all these GNU utilities into one executable, there's a
violation of the GPL to the extent that the code used to do that does
not appear to be "Open Source".  Double Whammy here.
And by the way - I AM a lawyer.  (Member of the Michigan Bar
Association in Good Standing).
   

I noticed that but i was wondering if these were actually cygwin tools.
Has anyone verified that?
 

In the support pages they show some registry entries that should be set, 
and they clearly show "Cygnus solutions\Cygwin" when talking about 
integrating "your application" into thinstall. Then again the compiler 
is part of their thinstall environment so I would assume that the "your 
application" was generated by their product.

Thinstall Studio Help - see page 60 for registry entries
http://thinstall.com/downloads/thinstall_help.pdf
Also from another site:
http://www.infolets.com/1042152373/
"To demonstrate the power of Thinstall the company has produced Unix 
Tools , a collection of 18 of the most 
useful Cygwin tools packaged into a single 1.1MB (floppy sized) EXE file 
that runs without any installation process."

8*{



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: subprocess i/o interaction with shell (bash&cmd): shells competefor input with user program!

[Steve Coleman]

Sam Steingold wrote:

I am not using fork().
just plain exec().
 

If thats the case then the exec() you are linking is not behaving as a 
POSIX exec() call, because if it did you would not still have two 
processes to even compete for the I/O streams. The first process image 
would be "replaced" by the second.

% man execl

8< -
"The  exec family of functions replaces the current process image with a 
new process
image."
-

So, either you are not using Cygwin execl(), or it is VERY broken, which 
I doubt because too many applications have been working correctly for 
too long for the second to be the case.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Spammers watching this user forum

[Steve Coleman]

Earnie Boyd wrote:

When you bounce that type of SPAM then you are participating in the DoS. 
I agree completely with this statement, and although I though the idea 
of "wpoison" was technically "cool" it also does nothing to ebb the 
tide, and in fact only increases the level of the floodwaters by causing 
the spammers to generate more bogus emails that need to be sent and 
processed. SpamAssasin is also "cool" but once the spam is already on 
the network its bad-news no matter how it gets stored, filtered, and 
processed. Even the best of filters have their downside and most don't 
throw anything away in fear of a "real" email getting tossed. I for one 
would love to see a more "active prevention" of spam!

My current thoughts.. Most spammers use open relays as their way to move 
their email into the legitimate Internet email system So, modify an smpt 
like process to look like a normal sendmail, only it will forward just 
one or two messages (i.e. the spammers open relay test) for each 
connecting host and then log that host and email address into a database 
as well as reporting the host to the RBL, ISP, etc.. For any subsequent 
access from that address this process should simply "eat" the email but 
act as if it is accepting and delivering it. For each subsequent email 
received from that host address it simply delays the connection flow 
like the LaBrea tar-pit project did it, thus limiting the connection 
bandwidth and slowing their delivery engine to a snails pace. This 
essentially captures the spammers sending process while while 
simultaniously dumping what little they manage to get out the door to 
straight to /dev/null. No filter processing required! As long as I don't 
pay for the minimal/controlled bandwidth, and I play nice with others, I 
probably won't even know they are trying to abuse me since it would take 
near zero cpu cycles to toss everything.

Face it, anybody trying to use my PC to send an email is obviously up to 
no-good, and I don't grantee delivery since they are not paying for my 
services. If they find something living on my port 25 I never said it 
was a "sendmail", that’s just their assumption. If enough machines on 
the internet listened on port 25 out there and "ate" all the spammers 
junk like this then the spammers would have a tough time staying in 
business by trying to use open relays, because they would never know if 
their cruft was /dev/null'ed or not. If they stop using open relays then 
all the RBL's will work like a charm even without all the fancy AI 
filters! Less traffic, less storage, less processing, everybody wins. 
All the spammers would know is that it took a VERY-LONG-TIME to send 
everything, so maybe its just a slow network? - lol

Sorry for this rant, but as not to be too off-topic, if I ever did do 
something like this in the future then Cygwin is going to be the 
“perfect weapon” to fight back with, because there are lots of machines 
out there running Windo$e, and the more tar-pits out there the better! 8^>

Since this is not completely Cygwin related, please contact me off-line 
if you have any comments or ideas on this topic.

Steve.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Big Brother is Real

[Steve Coleman]

Randall R Schulz wrote:

I think we have to work with the legal system, not try to subvert it. 
Microsoft has a right to set the licensing terms it wants. We have a 
right to tell them to go to hell. Currently however, and as you note, 
the power relationship is highly skewed. It ain't easy to "just say 
no" to Microsoft.
And in some cases you can't say "no"!

A long time ago (showing my age here - lol) when I worked for NASA, I 
first cut my teeth on Cygwin out of desperation to get my job done on a 
Wintel box. The very fact that it did not possess anything even close to 
resembling real POSIX was a constant thorn in my side on a daily basis. 
At the time I was a representative to the X/Open organization and was 
heavily involved in the system benchmarking and conformance testing to 
ensure that all equipment supplied on several large contracts adhered to 
the X/Open standards. That is until the M$ "legal suites" showed up in 
force and muscled there way in through legal threats. Can you imagine 
that? NASA, as big of a government organization as it is, being muscled 
and pushed around by Microsloths lawyers to accept Windows as an X/Open 
complient operating system? Without Cygwin Windoze would never even come 
close to being X/Open complient, and Cygwin at that point was still in 
its infant stages of development. The short story is that M$ intimidated 
NASA into creating a contract just for M$ to sell their stuff even 
though they were not compliant with any of the benchmark tests or 
feature lists required in order to compete.  If you can't compete 
technically (or just need some spare cash on hand), just threaten to sue.

Thank you team Cygwin! ;-)

(These are my own thoughts and opinions and in no way reflect my current 
or past employers positions in any way)

8*}





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Ping program?

[Steve Coleman]

Hopkins, Samuel wrote:

I need the sourcecode to modify. =(
 

If you *must* have a ping program that does something *special* then you 
might want to look at libpcap (www.tcpdump.org) and libnet 
(www.packetfactory.net) libraries then you should be able to implement 
whatever functionality you may need, but this (cygwin) would not be the 
correct forum to discuss such a project. Both of these networking 
libraries are available for Win32 and together they let you do almost 
anything you might want. Those sites should have ping-like examples for 
you to start out with and their own listserv.

Steve

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup.exe: something besides C++?

[Steve Coleman]

Pavel Tsekov wrote:

On Wed, 5 Mar 2003, Joe Buehler wrote:

 

but have any of the setup.exe
developers thought about changing setup.exe so that it is written
in something a little easier to work on, like perl/tk?  

But then, it would become _huge_. You'd have to download a bunch of other software just to install Cygwin.

True, It would hardly make sense to have to install Cygwin & perl/tk 
just to install Cygwin! (lol)

But then with all the recent requests for new Cygwin setup.exe features 
I do think there might be a use for something like the CPAN.pm package 
that would allow these people to script their own automatic updates or 
to add new custom features as required for their specific needs. No 
setup.exe is going to satisfy everybody, so perhaps a CYGWIN.pm ??

e.g.
%> perl –MCYGWIN –e ‘install XFree86’
It wouldn't replace setup.exe since the initial install would still have 
to be done but it might be a good idea to have something that could 
check if there are updates to designated packages that are deemed 
important to the specific Cygwin user, and notify or even just perform 
the updates like the "Windows Update" service. One administrator might 
grab the latest packages and store them on a corporate server and all 
the workstations via crontab could then install from their central file 
server thus easing the load on all the Cygwin mirrors.

Steve

P.S. - many thanks to the Cygwin maintainers!! ;-)







--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/