Menu
▾
▴
nasm-users
|
From: brutus <mad...@gm...> - 2003-10-15 22:43:45
Attachments:
EchoClient.asm
|
hello all. some time ago someone asks for winsock examples, so i tried to port some of my old tasm code to nasm, but i cant't manage to get it working. as far as i noticed i've got at least 3 problems: * 01 * while debuging, OllyDbg[1] remarks that my entry point is outside the codesegment and complains about beeing outside the code segment when i set breakpoints. don't know what this is all about. seems that everything works fine none the less. i got the same errors with a small hello-world-box program, i wrote to test this. * 02 * another strange one: the message box that is used to display the error messages don't have a titlebar or border or anything. just a grey background the text and the ok button. this happens no matter, which position in the code the message box is called. if i use a wrong ip addresse to generate an error f.e. the message box is also displayed this wired way. * 03 * the connect call returns -1 (SOCKET_ERROR) to indicate an error. WSAGetLastError() returns 0x271E (10014d) = WSAEFAULT(win), EFAULT(bsd) and i realy don't know why. judging by the return values and the OllyDbg sessions, the initializing of WSA, the socket creation and the setting of the sockaddr_in structure are working fine. here's a dump of the sockaddr_in structure: ... 0040218A 00 00 00 00 4C 00 00 00 ....L... 00402192 02 00 00 07 7F 00 00 01 .... 0040219A 00 00 00 00 00 00 00 00 ........ 004021A2 00 00 00 00 00 00 00 00 ........ ... 0040218E = socket handle 0000 004C 00402192 = sockaddr_in structure word: addresse family, word: port, dword: ip (127.0.0.1) and 8 zero bytes i work under winxp and use nasm -f obj echoclient.asm to assemble and alink -c -oPE echoclient.obj to link. so, hope to hear from you guys/gals. later brutus [1] http://home.t-online.de/home/Ollydbg/ |
|
From: Frank K. <fbk...@co...> - 2003-10-16 01:07:54
|
brutus wrote: Hi, Brutus! Thanks for joining us. I'm *way* over my head on this stuff, but debugging code by clueless trial-and-error is something I'm gaining experience at :) > while debuging, OllyDbg[1] remarks that my entry point is outside the > codesegment and complains about beeing outside the code segment when i > set breakpoints. Adding "class=code" to the segment declaration seems to fix this. I added "flat", too. Dunno what it does, but it sounds cool :) I think it's the "class=code" that fixed it. > another strange one: the message box that is used to display the error > messages don't have a titlebar or border or anything. just a grey > background the text and the ok button. This one I'm not seeing. When I try to run the (modified by "class=code flat") executable, I get a normal-looking messagebox with "Error connecting to server..." as the text. That's as far as I've got - just thought I'd mention the "class=code" thing. Research continues... Later, Frank |
|
From: Yeoh H. <ye...@ye...> - 2003-10-16 02:24:52
|
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the win32-nasm-users group. File : /yeohhs/calldialog.zip Uploaded by : yeohhs <ye...@ye...> Description : Call a dialog box from a menu item: a variation of Iczelion's example. :-) You can access this file at the URL http://groups.yahoo.com/group/win32-nasm-users/files/yeohhs/calldialog.zip Best Regards, Yeoh -- <ye...@ye...> |
|
From: brutus <mad...@gm...> - 2003-10-16 18:46:10
|
Frank Kotler wrote: > Hi, Brutus! > > Thanks for joining us. I'm *way* over my head on this stuff, but > debugging code by clueless trial-and-error is something I'm gaining > experience at :) > >> brutus wrote: >> while debuging, OllyDbg[1] remarks that my entry point is outside the >> codesegment and complains about beeing outside the code segment when i >> set breakpoints. > > > Adding "class=code" to the segment declaration seems to fix this. I > added "flat", too. Dunno what it does, but it sounds cool :) I think > it's the "class=code" that fixed it. hmm, great! works for me too. as far as i understand it, the flat thing just makes sense in Os/2 programms (see below). if i used it, my code seg just becomes part of a group called flat. you can verify this if you look at the map files of your linker (use -m with alink to get it). the class=code options works, but i don't understand why. any hints someone? it *seems* to have nothing to do with the correct assembling/linking and don't *seem* to influence the prog. i think it's an OlyyDbg thing, maybe with the way OllyDbg decides if some segment is a code segment? if you uncheck DebugOptions/Security/"Warn when breakpoint is outside the code section" the warning won't get displayed anymore. here are some snippets i found in the nasm docs, that could clarify a bit: The Unix object formats, and the bin object format (but see section 6.1.3, all support the standardised section names .text, .data and .bss for the code, data and uninitialised-data sections. The obj format, by contrast, does not recognise these section names as being special, and indeed will strip off the leading period of any section name that has one. The obj format does not define any special segment names: you can call your segments anything you like. Typical names for segments in obj format files are CODE, DATA and BSS. The obj output format extends the SEGMENT (or SECTION) directive to allow you to specify various properties of the segment you are defining. This is done by appending extra qualifiers to the end of the segment-definition line. The available qualifiers are: * PRIVATE, PUBLIC, COMMON and STACK specify the combination characteristics of the segment. _PRIVATE_ segments do not get combined with any others by the linker; _PUBLIC_ and _STACK_ segments get concatenated together at link time; and _COMMON_ segments all get overlaid on top of each other rather than stuck end-to-end. * ALIGN _ALIGN_ is used, as shown above, to specify how many low bits of the segment start address must be forced to zero. The alignment value given may be any power of two from 1 to 4096; in reality, the only values supported are 1, 2, 4, 16, 256 and 4096, so if 8 is specified it will be rounded up to 16, and 32, 64 and 128 will all be rounded up to 256, and so on. Note that alignment to 4096-byte boundaries is a PharLap extension to the format and may not be supported by all linkers. * CLASS _CLASS_ can be used to specify the segment class; this feature indicates to the linker that segments of the same class should be placed near each other in the output file. The class name can be any word, e.g. CLASS=CODE. * OVERLAY _OVERLAY_, like _CLASS_, is specified with an arbitrary word as an argument, and provides overlay information to an overlay-capable linker. * USE Segments can be declared as _USE16_ or _USE32_, which has the effect of recording the choice in the object file and also ensuring that NASM's default assembly mode when assembling in that segment is 16-bit or 32-bit respectively. * FLAT When writing OS/2 object files, you should declare 32-bit segments as _FLAT_, which causes the default segment base for anything in the segment to be the special group _FLAT_, and also defines the group if it is not already defined. * ABSOLUTE The obj file format also allows segments to be declared as having a pre-defined absolute segment address, although no linkers are currently known to make sensible use of this feature; nevertheless, NASM allows you to declare a segment such as SEGMENT SCREEN ABSOLUTE=0xB800 if you need to. The _ABSOLUTE_ and _ALIGN_ keywords are mutually exclusive. NASM's default segment attributes are PUBLIC, ALIGN=1, no class, no overlay, and USE16. |
|
From: Yeoh H. <ye...@ye...> - 2003-10-16 01:20:03
|
Hi Brutus, I tried to compile EchoClient.asm and got a type not defined. The error is in line 60 wsaData resb WSAdata_size ; stores data about WinSock I checked the definition of WSAdata in win32n.inc and found that it is WSADATA. So I changed this line to: wsaData resb WSADATA_size ; stores data about WinSock After this EchoClient.asm compiles and links without any problems. :-) When I test run the program, a message box with caption "[ERROR] WinSock Echo Client" appears and the text message is: Error connecting to server... Yes, this is expected because I don't have EchoServer running. If you could post EchoServer.asm, I'll try it out and let you know the results. :-) Best Regards, Yeoh -- |
|
From: Frank K. <fbk...@co...> - 2003-10-16 04:18:23
|
Yeoh HS wrote: > I checked the definition of WSAdata in win32n.inc I've got three win32n.inc's here... this is something from "The_Owl" WIN32N INC 139,841 04-01-00 2:02p win32n.inc this is "Tomcat"s - I assume it's the one we want WIN32N INC 290,400 05-11-99 3:34p WIN32N.INC and this from "Gaz"s win32nasm package(?) WIN32N INC 1,029,613 07-07-03 2:52p win32n.inc I don't know if it's got anything to do with the case of WSAdata, but there's a potential problem looming here. I've got 13 "windows.inc"s, too, but mostly not for Nasm (one in Gaz's package). Only one "nagoa.inc" (well, another one in projects\toolbar - 3k), but it's a fairly old one - I'll bet if I downloaded the latest version, it would be different. And that's not including Sheroc's package... Maybe one of the things we could discuss on this list is which .inc is which, and which is best to use for what purpose. Gaz's package interests me, because it uses Nasm's "-f win32" format, rather than "-f obj". (and I liked some of his macros better than Tomcat's - which I think is what nagoa.inc is based on?) Needs a different linker to handle the MS COFF. I think the linker with LCC is supposed to work, and I've had some success with the ld from Cygwin, in addition to the MS product (which is included with the package). The website phoenix.gb.net seems to have died. You can get the "base pack" from Tomcat's site, but there's a larger package (looking at it... I guess the "base pack" has everything you need...). Anyway, I see potential problems if we try to assemble something that includes "some.inc" and we've got a file by the same name, but perhaps a "pre-bugfix" version... Is there a de facto standard for what you guys use? Best, Frank |
|
From: Yeoh H. <ye...@ye...> - 2003-10-16 06:20:35
|
Hi Frank, You're right. :-) There are several versions of win32n.inc. My version is: <extract> WINDOWS.INC for 32 bit NASM (Version 1.26e) Release 07 Jul 2003 ;; This is the NASM(XSTRUCed) version of WINDOWS.INC by sheroc & Jibz ;; </extract> The other include file I have is nagoa.inc: <extract> ; NAGOA.INC for NASM based on win32n.inc version 0.06 by Tamas Kaproncai [to...@sz...] ;================================================================= ; by PedroGC version 2 ABRIL 2003 </extract> These two include files appear to be updated in 2003 so I think I'll stick with these. Other "non-standard" macros, including my own, I think it's best to put them in a separate file for inclusion. :-) I wish there were a de facto standard. It would make code sharing and re-useability much easier. :-) Also, the build process can be different. In RadAsm, the build batch commands are set in RadAsm. For those who like to build at DOS command prompt level, the batch commands would be slightly different. In future, I think I'll add a build.bat to the zips so that the programs can also be built at DOS prompt. :-) Best Regards, Yeoh -- |
|
From: brutus <mad...@gm...> - 2003-10-16 18:46:16
|
Yeoh HS wrote in Re: [Nasm-users] winsock problem & strange errors: > I tried to compile EchoClient.asm and got a type not defined. > The error is in line 60 > wsaData resb WSAdata_size ; stores data about WinSock > > I checked the definition of WSAdata in win32n.inc and found > that it is WSADATA. > So I changed this line to: > wsaData resb WSADATA_size ; stores data about WinSock > > After this EchoClient.asm compiles and links without any > problems. :-) WSAdata_size works for me since it is defined as WSAdata in my include file. This is the WIN32N.INC i used: Win32.inc for NASM 1999 version 0.06 by Tamas Kaproncai [to...@sz...] MD5: FF818A0C2C2D76E8F68D3DDA1E7676BD WIN32N.INC And WSAdata is defined as: STRUC WSAdata .wVersion RESW 1 .wHighVersion RESW 1 .szDescription RESB WSADESCRIPTION_LEN+1 .szSystemStatus RESB WSASYS_STATUS_LEN+1 .iMaxSockets RESW 1 .iMaxUdpDg RESW 1 .lpVendorInfo RESD 1 ENDSTRUC Yeoh HS wrote in [Nasm-users] Mulitple versions of win32n.inc: > My version is: > WINDOWS.INC for 32 bit NASM (Version 1.26e) Release 07 Jul 2003 ;; > This is the NASM(XSTRUCed) version of WINDOWS.INC by sheroc & Jibz ;; > > The other include file I have is nagoa.inc: > NAGOA.INC for NASM based on win32n.inc version 0.06 by Tamas Kaproncai [to...@sz...] > ================================================================= > by PedroGC version 2 ABRIL 2003 > > These two include files appear to be updated in 2003 so I think I'll stick > with these. Other "non-standard" macros, including my own, I think it's best > to put them in a separate file for inclusion. :-) mine seems older so i will probably end useing one of those you mentioned above. > I wish there were a de facto standard. It would make code sharing and > re-useability much easier. :-) i absolutely agree! but i'm clueless which one is to be used. i just want to use nasm from the commandline paired with whatever linker fit's. with as less tools and extra stuff added as possible. so, as i know nothing about all those packages you mentioned, but will satrt google soon, i'm interested which you will recommend. later brutus |
|
From: Yeoh H. <ye...@ye...> - 2003-10-17 01:48:51
|
----- Original Message ----- From: "brutus" <mad...@gm...> To: <nas...@li...> Sent: Friday, October 17, 2003 2:24 AM Subject: Re: [Nasm-users] Mulitple versions of win32n.inc > so, as i know nothing about all those packages you mentioned, but will > satrt google soon, i'm interested which you will recommend. > > later > brutus Hi Brutus, :-) The packages can be downloaded from these sites: 1. Package by Sheroc is at: http://www.freewebs.com/remains/NASM32PACKAGE.exe From post at forum: http://sourceforge.net/forum/forum.php?thread_id=913933&forum_id=167168 <extract> Hey people, I have bundled a package of last NASM for win32 + Jibz XSTRUC macros + a WIN32N.INC ( 1,3 Megs, not Tamas Kaproncai´s, its a port of the known MASM32 WINDOWS.INC ) with quite a serious set of structs and equs ( based on XSTRUC macros )... Its a RAR SFX installer that sets up a ready to use layout, with a example and so on... </extract> 2. NaGoA is at: http://www.visual-assembler.pt.vu/ It's a big package, 6.69 Mb. I don't use its IDE and other tools so I had extracted the headers and support example files. Best Regards, :-) Yeoh -- |
|
From: brutus <mad...@gm...> - 2003-10-16 18:46:08
Attachments:
EchoClient.asm
|
hey again. thanks for you comments. i've cleaned up the code a bit, put all the stuff in the .bss seg into the .data seg and define all equ's so i don't need the include file. i also include a welcome message box at the beginning. the welcome box works for me but i still get the strange box when i get the error message. hope someone can test the new code and tell me if it works for him/her. if so please tell me which options/linker you use. i still get the "can't connect" error and don't know why but i first want to get rid of the strange box before i explore this deeper. if someone want's to test it, i could send you an echo-server (but it's in perl) or you could use netcat[1]. simply type "nc -L -s 127.0.0.1 -p 7" in the shell (cmd.exe). thanks again and later... brutus [1] http://brutus.dyndns.info/stuff/netcat11nt.zip |
|
From: Frank K. <fbk...@co...> - 2003-10-17 01:09:13
|
brutus wrote: > the welcome box works for me but i still get the strange box when i get > the error message. hope someone can test the new code and tell me if it > works for him/her. if so please tell me which options/linker you use. Both boxes look normal here. Options exactly as in the file. I *was* linking it with "path/to/alink/win32.lib", but find I don't have to - that's because you use the "IMPORT" lines, right? Linking with tlink32 (which often works identically with alink) gets me an invalid page fault, but that's a command line issue, I imagine. One difference is - I'm using Win98 - your mention of "cmd.exe" makes me think you're using NT/2k/XP(?). I don't know what difference that should make. Best, Frank |
|
From: Yeoh H. <ye...@ye...> - 2003-10-17 02:19:51
|
----- Original Message ----- From: "brutus" <mad...@gm...> To: <nas...@li...> Sent: Friday, October 17, 2003 2:44 AM Subject: Re: [Nasm-users] winsock problem & strange errors > hey again. thanks for you comments. i've cleaned up the code a bit, put > all the stuff in the .bss seg into the .data seg and define all equ's so > i don't need the include file. i also include a welcome message box at > the beginning. > Hi Brutus, :-) Yes, the welcome message box is displayed. > the welcome box works for me but i still get the strange box when i get > the error message. hope someone can test the new code and tell me if it > works for him/her. if so please tell me which options/linker you use. > When nc was not running, the Error message box appears. Same as the last time, with caption, text and button. > i still get the "can't connect" error and don't know why but i first > want to get rid of the strange box before i explore this deeper. if > someone want's to test it, i could send you an echo-server (but it's in > perl) or you could use netcat[1]. simply type "nc -L -s 127.0.0.1 -p 7" > in the shell (cmd.exe). > When nc was running, no message box appears. The program exits quietly to DOS prompt. My batch file to compile and link is: nasmw -ic:/nasm/inc/ -fobj EchoClient.asm alink -c -oPE EchoClient.obj > thanks again and later... > brutus > > [1] http://brutus.dyndns.info/stuff/netcat11nt.zip > Hope this helps. :-) Best Regards, Yeoh -- |
|
From: brutus <mad...@gm...> - 2003-10-17 13:37:31
|
hmm, i tried it under a win98se box and it works fine, just like you guys describe it. seems to be a xp thing. |
Thanks for helping keep SourceForge clean.
X