Posts by Tight_Coder_Ex

Definately, as that is what I try to do with my apps, espcially those with high interation loops. I found that link pretty easy, so maybe do your query more like a question that keywords.

Here is http://www.penguin.cz/~literakl/intel/intel.html instruction set with clocks

Keep in mind, in a multithreaded operating system, cycles are only realative as other concurrent processes are using CPU at same time, which will affect the throughput of application of interest.

Let's see what you've done so far

Sounds like one of these incidious errors and without seeing your entire code, I'm confounded to finding a solution

I'm not familiar with OpenGL, but I agree with taking a closer look at WM_SIZE as clicking in the non-client area and moving the mouse does trigger WM_SIZE. Most debuggers will allow you to trap an event based on the contents of register or memory, so catch the entry to WM_SIZE and see if it is triggered and single step to follow its path.

Look for any handlers you have in your app relative to non-client area such as WM_NCLBUTTONDOWN or UP.

You don't need line 18 or line 25 as getenv only takes one argument, that being a string pointer.

I generally like using kernel32 library functions and in this case may work for you

GetEnvironmentVariable

The GetEnvironmentVariable function retrieves the value of the specified variable from the environment block of the calling process. The value is in the form of a null-terminated string of characters.

DWORD GetEnvironmentVariable(
LPCTSTR lpName, // address of environment variable name
LPTSTR lpBuffer, // address of buffer for variable value
DWORD nSize // size of buffer, in characters
);

Line 26 would be replaced with

invoke GetEnviromentVariable, lpName, lpBuffer, nSize

or

push    nSize
        push    lpBuffer
        push    lpName
        call      GetEnvironmentVariable

Maybe consider writing a small boot loader and use BIOS calls instead. Most of the functionality you need is provided by any of the PC BIOS's. That way you are completely independent of any operating system including DOS. As your project develops, then inevitably you can get rid of any BIOS dependence too like Linux

You can also let 'c','p' & 't' fall through to 'g'

switch (ch)
	{
		case 'c': 
		case 'p': 
		case 't': 
		case 'g': cout << "Option '" << ch << "' selected\n";
                             break;

		default : cout << msg;
			cin.clear();
			while (cin.get() != '\n')
				continue;
			invalid = true;
	}

try

invoke RegOpenKeyEx HKEY_LOCAL_MACHINE, ADDR szRegSubKey, NULL, KEY_ALL_ACCESS, ADDR hKey)

I see what you mean in respect to the first example and the only conclusion I can come too is although new processors are backward compatible, but there are problems when attempting to use the high order bits of a 16 bit value. If you have access to a 286, see if there is a difference.

The remainder problems, I can't really figure out what your driving at there, but using the bx or bl registers does give me the desired result of 774 in ax and 8 in dx

int TxtSize = GetWindowTextLenth (hwndEditBox) + 1;
char *Entry = new char [TxtSize];
GetWindowText (hwndEditBox, Entry, TxtSize);
MessageBox (NULL, Entry, "", MB_OK | MB_ICONINFORMATION)
delete Entry [];

I'm pretty rusty at C++, so note useage of NEW & DELETE

When creating an "EDIT" window there are several flags associated all begining with ES_. The one you want to use is ES_AUTOHSCROLL in dwStyle.

Assuming your using CreateWindowEx, change the value of y (vertical position of window) before the next window is created.

Similar to goto statements, I've found multiple return paths are as equally problematic. If line 25 is executed then hFile is still open

The only thing I can think of is that another process or instance of this application already has the file open, and because you are not sharing the file this would not allow the handle to be created. Other than that, your code is correct.

Set a soft break at CreateRawDataBUFR then a watchpoint at rdi, or set the same softbreak and a watchpoint to the location where rdi is stored and another at the contents that rdi points too. Then by single stepping see which changes at what point int the subroutine.

If you don't return a value to the operating system, then whatever happens to be in EAX at the time will probably be returned and this may cause undesirable results. That is why void main () is a definite NO NO!

#1: When you move 85 55H into Fenster your result will be two ascii digits. What you've done is added 48 to 85 and then 48 to your terminator $. This might help you out

Fenster     db    85, 0, '$'

mov   dx, offset Fenster
mov   ax, Fenster
push   ax
and    ax, 15
add    ax, 48
mov   dx, al
inc     dx
pop    ax
shr     ax, 4
add    ax, 48
mov    dx, al
dec     dx

I'm not advicating this is the best way to do it, but based on your logic this is probably the closest approximation based on your code

I'll be away for a bit so I'll give you the snippet regardless. This is written for an XP based machine, but I'm sure you'll be able to improvise.

push edi
mov al,30H ; Ascii equivalent to "0"
mov edx, 913387 ; You can make this any value
std ; set EDI to auto decrement
mov edi, 401087
.D0 mov al, dl
and al, 15 ; strip bits 7 - 4
or al, 30H
stosb
shr edx, 4 ; shift next digit
jnz .D0
mov eax, edi
inc eax
pop edi
cld
pop edi

This method leaves base address of string in EAX, but you can put it anywhere.

This only works if you are displaying decimal digits. You'll have to modify loop if you want hex in order to display A - F.

If you really get stuck I can post a short snippet on the example Ancient Dragon gave you. Just to clarify you are using NASM on an intel based machine that uses Linux. The reason I ask is that I'm assuming in your first post rax actually means eax.

If your application is pure assembly then the way AncientDragon explained it is the only way unless you use BCD or want to display result in decimal. A lot of applications I do are for windows therefore I use wsprintf a function of kernel32.lib and then one of the parameters such as %d or decimal or %X for hex will do the conversion for me

Yes you will eventually run out of memory by continuously allocating with malloc and never freeing.

In the second case, theroetically you shouldn't run out of memory by freeing each time, but Linux and Unix like XP handle memory a lot better than 95 or 98 do. I have no experience with OSX, but assume it's similar to Linux. In 95 and 98 they just keep using memory until nothing is left and only relinquish it when application is closed. That is why you can run out of resourses with these two operating systems and have few programs running.

Long story short. It's good practice to determine how heap resourses are handled on the platform you are using and pay attention to those API's that will relinquish memory to operating system and/or coalesce fragmented segments while program is running.

If you have the oportunity to look at Linux man pages and sources that will give you a real good understanding how modern operating system handles memory.

Any other suggestions I would have are related to my personal preference as to coding style which isn't really realative to your situation. Generally the body of your application is sound or at least it achieves the objective. All you have to do now is add the part where holdPhrase is modified dependant upon users input.

Pointers and arrays of pointers are always problematic to understand, hopefully these changes will clarify for you.

#include <iostream>
using namespace std;
 
char *tarray [] = {"Alpha","Bravo","Charlie","Delta","Echo","Foxtrot","Gulf","Hotel",
"India","Juliet","Kilo","Lima","Mike","November","Oscar","Papa",
"Quebec","Romeo","Sierra","Tango","Uniform","Victor","Wiskey","X-Ray",
"Yankee","Zulu"};
 
int main (void)
{
char phrase [80], holdPhrase [80], letter;
 
cout << "Enter Phrase: ";
cin.getline (phrase, 79);
int sizeOfPhrase = strlen (phrase);
 
for (int x = 0; x < sizeOfPhrase; x++)
{
if (phrase [x] == ' ')
holdPhrase [x] = ' '; else holdPhrase [x] = '-';
}
holdPhrase [x] = 0;
 
cout << holdPhrase << endl;
 
do
{
cout << "Enter letter please: ";
cin >> letter;
cout << tarray [(letter & 0x5f) - 'A'] << endl;
 
cout << "Again: ";
cin >> letter;
} while ((letter &0x5f) == 'Y');
 
return 0;
}

In your example you never used tarray, so I assume I have it in the right place. You can replace

letter & ox5f;
toupper (letter);

either converts input to uppercase.

As defined in stdlib.h and malloc.h

free (q);

will do the trick. Assure only pointers that were created with malloc, calloc or realloc are passed to free (), otherwise other calls to get memory may have unpredictable results.

Please post errors and warnings. We don't have to study code in that much detail with that information

The answer is: Dev-C++ by three lengths and a hoof!

Probably just as important if not more so is the text you use to learn the language. I've found

The Waite Group's C++ Primer Plus ISBN 1-57169-162-6

to be fairly comprehensive. Combined with the 1000's of tutorials on forums such as this and news groups, you should be well armed with what you need to learn the language.

Be careful with books though. 2nd 3rd and 4th editions usually come out fairly quick and you will pay the price of the book all over again. Usually there is never enough change in content to make the additional purchases worthwhile.

The best
http://www.intel.com/software/products/compilers/cwin/

Good luck.

Well I don't think this kind of rhetoric is appropriate for this or any other forum and I beleive when someone charactizes something as the best it's with the utmost sincerity and should be taken in that context. I have never used Intels compiler, but have taken it upon myself to investigate furthur, based entriely on Intel's opinion.

So Narue, I think you should mabe reconsider your position as self proclaimed officer of etiquette, and as I've noticed with a lot of your posts not be so condesending and critical of what others write.

Maybe try C++ Primer Plus, Sams Publishing ISBN 1-57169-162-6. It's a 1000 pages of excelent text with many good examples. I've found the "DUMMIES" series are just money makers and don't have very meanigful content. Most often the most itellegent people assume they are dummies and those books specifically written for them.

Good Luck