Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: Assembler Date: Wed, 18 Feb 2004 08:02:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Williams, Gerald S (Jerry)" To: X-OriginalArrivalTime: 18 Feb 2004 13:02:29.0248 (UTC) FILETIME=[76B4B800:01C3F61F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id i1ID4d31031222 Krzysztof Duleba wrote: > Why not? c code, translated to asm with -c -S on linux box, > can be later compiled and linked with Cygwin's gcc and works > fine. As you see, I have a good reason to believe that nasm's > int 0x80 will work too. So maybe I should simply look for a > nasm -> gcc's assembler translator? int 0x80 is part of Linux, not nasm. In fact, nasm was generating the int 0x80 instructions just fine--they simply don't work under Windows. So such a translator wouldn't help. Cygwin does a great job translating many of the system calls, but these are invoked via function calls, not Linux internal software interrupts. By asking for int 0x80 support, you're really asking for the ability to run precompiled Linux applications. Googling brought me to http://line.sourceforge.net, which may be more along the lines of what you seek. -Jerry -- 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/