|
some code that was compiling good under VC6 can fail under VC7 because not Standard C++ compliant anymore...
what is the failling code please ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
I'm trying to rewrite an assembly program in C++. Instead of reinventing the wheel, I am cutting and pasting a lot of asm into __asm blocks. However, whenever I try to call int 0x21, I get an unhandled exception. Why is this and how do I get around it?
|
|
|
|
|
In this case you need to reinvent (most of) the wheel. The call int 0x21 (MS-DOS call) is probably allocating memory from the Upper Memory Area (UMA), which implies 16-bit code (old code). I am just surprised that that is the only problem you are asking about.
If you need to rewrite this old code, then you need to understand it:
1) You need to know what programing language the assembly code was ment to be accessed from (assuming it is not entirely in assembly).
2) Which version of the compiler was used (if possible).
3) Which processor it was written for (probably intel386).
4) What each of the assembly commands mean (+ what each function call does).
5) etc...
6) Break out or find the old books, on the calling language and the assembly language used.
The fact that you are trying this implies that you have a good idea of what you are attempting to do. If the assembly code (that calls int 0x21) represents a function call and you just copied it into and __asm block, in a C/C++ function, then post the funtion code.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
The assembly program was a stand alone application; it was not called from anywhere. I wanted to add some functionality to it, but it's been so long since I've programmed in asm that I've forgotten most of it. The compiler that was originally used to compile it was a86. It was written for the 286 intel processor. (16bit only) I'm familiar with most of the code and what it's supposed to do since I had left some comments here and there, but this is the first time I've ever tried to put asm and c++ in the same program.
Here is a block of code that's causing me problems:
;//;open file using handle (r/w)
lea dx, name
mov ax, 3D02h
int 0021h
jc end
xchg ax, bx
basically what it does is load the address of filename in memory into dx. name is a NULL terminated char array defined in the main() function. Then move 3D02 into ax. This will cause int21 to call function 3d which is the open filename command. The 02 byte in AL specifies to open the file in r/w mode. Then int21 is called to open the file. Afterwards the Carry flag is checked to see if the open was a success or failure. This should catch any errors with the open and prevent the program from crashing. (and yes, the label "end" is inside the same __asm block as the above code). Finally ax and bx are exchanged to put the file handle in bx. The next function called in asm code will require the handle be in bx, so might as well put it there now.
I debuged the above code and it crashes when it gets to the call to int21. I'm not sure what to do from here.
Also, I'm running Windows XP with a NTFS filesystem. When I run the asm code after it was compiled with a86, it runs fine. 
thanks!
|
|
|
|
|
I was thinking about a function call such as this (so I could call it):
return_type OpenFile(char* name)
{
__asm {
lea dx, name
mov ax, 3D02h
int 0021h
jc end
xchg ax, bx
...
}
...
}
Anyway, it does not matter.
I would go ahead and reinvent the wheel; actualy you are not reinventing the wheel, you are just bring it up to date. Things like accessing file I/0 should be handle at the current language level (things change). The only reason for keeping any of the code at assembly level is for speed.
Any of the assembly code you wish to keep and wrap in a function call should be wrapped in C function calls, so you do not have to deal with the difficulties (name mangaling) of C++.
Unless you are writting code at the driver level (ring 0), you normaly do not need to write assembly code. Modern day compilers are very good at otimising your code. Plus the fact that writting your code in C/C++ is much easier to understand (and modify).
Understand this: Under Win2000 and above the system will get upset if you try to access memory (read/write) without the proper security clearance, this is intended to defeat crackers/hackers.
__asm can be very useful, in time criticle applications. For good examples of its usage, see the source code for memset() and memcpy().
I know that I just told you to reinvent the wheel, but I realy beleive that is the best way to accomplish your goal (less headacks and, yes, less time in the long run).
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Interrupts are GENERALLY NOT ALLOWED in Windows!
There is only one exception: Interrupt 2Eh, which is used for communication between user mode and kernel mode.
Every other interrupt should cause an exception because it can only be called from Ring-0!
Don't try it, just do it! 
|
|
|
|
|
Are you really sure you couldn't just recreate this assembly language program's functionality in a straight C++ application? Almost anything you try to do via int 0x21 is an MS-DOS function call, which may or may not be emulated in the Windows environment (depending upon how you're running your application). The unhandled exceptions you are seeing are probably related to access denials.
Software Zen: delete this;
|
|
|
|
|
I'm sure I can recreate the program in strait C++. It just would be easier to reuse my old code if it were possible. If you truely can't use any interupts except 2E in __asm blocks under windows, then I don't see where __asm blocks would be useful for anything. In all the asm programs I've written, the code has consisted of mostly shuffling registers and interupt calls. Without using interupts, how can assembly language be useful for anything?
|
|
|
|
|
CorvetteZ0606 wrote:
Without using interupts, how can assembly language be useful for anything?
Unless you are using DOS-specific interrupts, or those that deal directly with hardware, you can do numerous things. But most assembly code has been "wrapped" by a much friendlier function. Since device drivers operate at ring 0 instead of ring 3, they are loaded with assembly code.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Assembly language still has its uses, even in modern Windows applications. The most common used are to either hand-optimize code that is performance-critical, or to use specific instructions out of the CPU instruction set.
Consider this, however. In over ten years of Windows application development, I've never had code that was so performance-intensive that I felt the need to write assembly language to speed it up.
Software Zen: delete this;
|
|
|
|
|
Summary:
m_hWnd is NULL in a CDialog derived class and this leads to an assertion failure.
Details:
I am writing an SDI application. I've subclassed a CDialog class that will popup and gather info from the user. In response to the user clicking some button the Document class handles the message and creates a new CDialog object and calls DoModal(). The basic idea is something like this:
<br />
void CMyDoc::OnButtonClick()<br />
{<br />
CMyDialog md;<br />
md.DoModal();<br />
}
Now, the CMyDialog class has a CTabCtrl named "m_tabSettings" with two tabs. I need to initialize these tabs and have tried to do so with code similar to this:
<br />
m_tabSettings.InsertItem(0,"Tab One");<br />
m_tabSettings.InsertItem(1,"Tab Two");<br />
This causes an assertion failure in AFXCMN.INL on the following line:
<br />
_AFXCMN_INLINE BOOL CTabCtrl::InsertItem(int nItem, LPCTSTR lpszItem)<br />
{ ASSERT(::IsWindow(m_hWnd)); return CTabCtrl::InsertItem(TCIF_TEXT, nItem, lpszItem, 0, 0); }<br />
The key part from above is: ASSERT(::IsWindow(m_hWnd));
I stepped through this code in the debugger and sure enough m_hWnd is 0x00 when I try to insert tabs into my CTabCtrl. I'v tried the following:
1. moving this 'insert item' code to the CMyDialog constructor (actually this is where I had it to begin with)
2. moving the 'insert item' code to a separate function which I call between the dialog declaration and DoModal()
3. changing the CMyDialog variable to a pointer and creating a 'new CMyDialog' on the heap
4. calling CMyDialog::Create() before the call to DoModal() ... and I played with creating a CMyDialog object from the CMyView class as well.
5. getting rid of the tab control initialization code altogether and inserting a CListCtrl in report form as a variable instead. I then tried to call CListCtrl::InsertColumn(0,"col one") ... etc.
All of these cause the same or similar assertion errors. I know, most of the stuff I've tried is some type of 'magic chicken coding' but I have no idea why code that I've pretty much copied from stuff I saw on the MSDN is breaking like this (i.e. I'm out of ideas) .
Is there some order of method calls that I'm missing or some flag for the CMyDialog?
If anyone has had a similar problem please let me know if and how they've fixed it.
|
|
|
|
|
You need to move the initialization to CMyDialog::OnInitDialog(), after calling CDialog::OnInitDialog(). Until that, the dialog controls aren't yet created.
You need to distinguish between the CWnd-derived C++ object that wraps the Windows control (e.g.: m_tabSettings) from the Windows control itself (e.g.: m_tabSettings.m_hWnd);
The dialog constructor constructs the control wrappers, DoModal first creates the Windows controls and then calls [1] OnInitDialog. CDialog::OnInitDialog associates each control wrapper with its corresponding window control.
[1] Actually, during the dialog creation, Windows sends a WM_INITDIALOG message, which is handled in the dialog by OnInitDialog.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
For those interested, I will now answer, at least in part, my own question.:
Solution:
Override CMyDialog::OnInitDialog() and initialize the CTabCtrl there.
As far as I've traced it, CMyDialog::DoModal() calls CDialog::DoModal() (i.e. the base class fn.). This I knew. What I didn't know is that CDialog::DoModal() calls my OnInitDialog() (or some funtion up(down,whatever) on the call stack before DoModal returns does). I just assumed that CMyDialog's constructor was calling OnInitDialog() . So, CDialog::DoModal() apparently initializes some stuff behind the scenes before it calls OnInitDialog() which allows me to init my controls safely.
It is late and I am too tired to dig further.
If anyone out there understands the sequence of behind the scenes initializations or whatnot that happens between the call to CDialog::DoModal() and the call to OnInitDialog() please explain.
|
|
|
|
|
Bah! Thats what I get for reading my post too many times before I click 'submit'. Thank you for your reply Jose!!
|
|
|
|
|
Hi There,
What's the best solution to use and implement an Array with maxixmum size of elements?
Thanks
|
|
|
|
|
SHORT ANSWER:
Use the standard template vector<> (#include <vector>).
If you know the (aproximate) number of elements needed for storage, before coping, then call the member function reserve(), in order to reduce the number of reallocations required when adding new elements to the array.
LONG ANSWER:
The best solution depends on how it is going to be used (implimentation dependent). If you need a dynamic array (increases/decreases size as needed) then use the vector<> template (which is a one dimensional dynamic array). The maximum size of an array of elements, depends on the size of the elements and amount of memory available.
If you use a vector, you can call the max_size() member to determine what is, theoretically, the maximum number of elements that can be stored in a vector. I say theorectically because it, again, depends on the size of the element being stored, the amount of available memory and the amount of contiguous memory that can be allocated (on a given system).
THAT'S ENOUGH:
In C++ just use vector<>, unless you have a good reason not to.
NOTES:
1) Never use type* pArray = new type[size] when type Array[size] will solve the problem.
2) Prefer:
vector<type> myarray;
myarray.reserve(size);
TO
type* pArray = new type[size];
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
hi,
have an SDI application where the view class has been derived from the CFormView class. i added a list control to the dialog. but when i tried to add some sample text to it i got and exception. in some earlier posts someone had suggested to define the virtual function DefWindowProc. and in the handler for the WM_INITDIALOG message call UpdateData(FALSE). i tried that but i am still getting the exception. can anyone help
thanks
aditya
|
|
|
|
|
I assume you have a member variable that has been subclassed to the control in question. This might have been done for you. Use the debugger to make sure that m_hWnd is not NULL prior to adding the sample text to the list box. If it is NULL, make sure that the resource ids haven't changed and that the control id is correct for the control. This often causes problems.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I'm looking for a "multi-slider" control that contains n (>= 1) knobs to allow for the definition of contiguous ranges. An example of one with 6 knobs would look like this:
(min)...|.......|..|....|.......|...|..(max)
1 2 3 4 5 6
A pointer to existing code would be much appreciated. Thanks!
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
|
it took awhile to figure out what the correct image link was, but here it is [^]
seems there are tons of broken links on CodeGuru... 
Steve
|
|
|
|
|
Steve Mayfield wrote:
seems there are tons of broken links on CodeGuru...
No surprise. 
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
|
Strange occurance ?
In one dialog, i call this
myDlg = new CmyDlg;
myDlg ->Create(IDD_DIALOG, GetDesktopWindow());
myDlg ->ShowWindow(1);
Now I have a thread running, if it receives a message, it'll sometimes popup a MessageBox window, but the MessageBox will be under everything. I want the message to popup ontop of everything.
If I call from the thread, with MessageBox(GetForegroundWindow(),...); It'll popup the message box, but then the application will lock.
Not sure what's causing it, and if I do MessageBox(NULL,...) it'll run fine except the MessageBox is under everything ..
?
|
|
|
|
|
I got it, just tagging MB_SYSTEMMODAL to the function.
Btw, why does it do that ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
