dan63043

The "db" literally puts your characters into memory, there is no "escape" mechanism. You can't use that interrupt in the manner you are trying. It will even "print" unprintable characters, it is very literal. You need a different interrupt. Just search for Ralf Brown's name: "Ralf Brown's Interrupt List" is …

Strange. Presumably DOS, or you'd get nothing. I notice the lack of a return statement. The control chars may appear at the beginning of the line, but that doesn't mean they were printed before your message. You might be running past the end of your program, and hitting something that …

Actually, the ORG doesn't appear anywhere in the program. The ".COM" file extension informs [I]MS-DOS[/I] that the first byte of the file is executable code. The ORG instruction informs the [I]assembler[/I] that the first byte of executable code always starts at an exact offset.

You thought that memset would put an integer 5 into each element of your array, but that isn't how it works. It is putting a 5 into each byte. 5*256*256*256 + 5*256*256 + 5*256 + 5*1 = 84215045

Well, just my two cents, I only lurk in these forums because I otherwise don't get enough practice at C, which will soon be a significant part of my job for the first time in many years. First, you don't give any type to the arrays. Also, unless you define …

How will the user enter the number? Will you get it in ASCII? What operating system?

Try: [CODE]struct poly { int len; char *name; int arr[]; };[/CODE] BTW, your structure won't alway take up the same number of bytes. That might be fine for a particular situation.

See if this helps: [url]http://www.arl.wustl.edu/~lockwood/class/ece291/books/CH20/CH20-3.html[/url]

You just use the command string as the argument, so (in unix) to delete "/mypath/myfile", you do: [CODE]system("/usr/bin/rm /mypath/myfile");[/CODE] I tend to use the path when I know it, but: [CODE]system("rm myfile");[/CODE] might do as well. In Windows, use "del", not "rm", and don't forget that a backslash is a …

There are a million ways to do anything in C, and I'm glad someone got it to compile. Personally, rather than: [CODE]struct RECORD *head=(struct RECORD*)malloc(sizeof(struct RECORD));[/CODE] I would have done something like: [CODE]struct RECORD *head=(RECORD *)malloc(sizeof(RECORD));[/CODE] Actually, I would also check that malloc worked.

The C compiler will cause the executable to save and restore certain registers before and after a call, but not others, so the point of this exercise must be to get you thinking along those lines. Your assembly program calls the external function "find_avg", so you don't know that DI …

Those functions could be in some library that I don't have, but perhaps writing those functions is the REAL assignment. Could you give us some idea what assembler you use, on what operating system, etc? Maybe even the name of the course and book would give us a hint on …

Ummm.... actually do your assignment for you? How about a little effort... or at least some idea why you are so completely stumped that you haven't generated any code.

I just can't bear the thought of deciphering what your variables represent. You need meaningful variable names. Also, indent your control structures so that you know what is nested. (You may just need to use the code brackets.

You need a terminating null character, \0. You could add it any number of ways. If you just change "for(i=0; i<n2; i++)" so that "i" goes from 0 to "n2" then it will copy the null at the end of the second string to your new string.

If memory serves, it could be any even address on the 16 bit processors. Of course, if you're running 16 bit code on a 32 bit processor, go with divisible by four.

You never initialize time1, time2, or time3. Perhaps they have random garbage that isn't less than 1. But then why print zero? I don't know, but I like to test values AFTER giving them a value. I don't know why you're testing the value, anyways.

You can be sure that you are expected to do the if/else inside the function that gets the data. That is fairly standard practice, as it allows you to reuse the function to do validation in other modules, and a change in the allowable values will be implemented everywhere with …

deostroll, I can see that you're doing this in DOS. If your execution actually begins at "mov ax,3", then the "var db '$'" is executed next. $ is just a counter of the current program position, so it is a somewhat random opcode that depends on the address. You need …

There must be no stack segment, that is the biggest problem I remember having with exe2bin.

You will still use the x86 instructions on the other processors that you mentioned. So, those books may be useful. The real question for an x86 book is what operating system the examples were created for, or maybe whether it was 16/32/64 bits.

As I recall, we sometimes needed to specify the jump to protected mode in a DB statement. Google for John Fine, he has something to get you over that problem, I think.