Hi.
I used malloc under DOS, and experienced strange behaviour from my prog.
It seemed the allocation didn't work as it should(prog hangs, etc.. typical memory violation errors)..
Is this a common problem in DOS, or am i not using the func. correctly..?
I figured since DOS is pre the service pack age, it contains bugs..?
Depends on
Version of Dos;
Compiler;
(Most Probably) your code.
As dos is a crap OS...it may be that another app is causing all the problems
OS: Dos v.6.22
Compiler: Watcom c v.11c
The only other prog running on the machine, is Ms network client.
I thought the error was due to an undersized char array, but i went through all declarations, and found none..
Posting the code in question might help someone see what the problem is. I've never had a malloc crash the system, but I have had it not work because there wasn't enough memory to satisfy the request.
Oh, and Fordy, if DOS is a crap OS, what are you doing here, and do you think Windows is better? DOS doesn't lock up like Windows does, and it's easier to program in.
Definition: Politics -- Latin, from
poly meaning many and
tics meaning blood sucking parasites
-- Tom Smothers
As dos is totally dead it's more of a question of why do any of us post here.....And I'm not going to answer as to why windows is better......that's obvious to anyone using it....and if you are posting with an MS operating system, I guess you will be using windows right now....or are you posting using DOS?Originally posted by WaltP
Oh, and Fordy, if DOS is a crap OS, what are you doing here, and do you think Windows is better?
My windows hardly ever locks up....Originally posted by WaltP
DOS doesn't lock up like Windows does, and it's easier to program in.
DOS allows any program to screw with the memory holding code/data for other programs and even the OS itself so it's easy for a misbehaving dos program to crash the system. With a proper windows NT platform on the other hand it's pretty hard to take down the system unless the faulty code is running in kernel mode (drivers)
As to Dos being easier to program in....again I disagree.....it's just a matter of spending a little time understanding how to program windows, then you have access to lot's of APIs and tools. Try code anything recent (say something web related, or ou want to use a current database) with DOS and your stuffed.
Sorry, I forgot the smily in my last post, I hope you took it the right way...
I'm not so sure it's totally dead. I still see a lot of systems that are DOS-like screens throughout retail, and I doubt most of them are running on the latest OS. I will admit it's definitely on the endangered list, though.Originally posted by Fordy
As dos is totally dead it's more of a question of why do any of us post here.....And I'm not going to answer as to why windows is better......that's obvious to anyone using it....and if you are posting with an MS operating system, I guess you will be using windows right now....or are you posting using DOS?
You're right, I am using XP. But I am in a DOS box during a lot of development. Being a professional, I do have to keep up appearances
You must have a charmed system, or XP. With my 98 system, I locked up many times a day. With XP so far it's rare, but it does happen.My windows hardly ever locks up....
Yes, but a quality program will have those bug squelched long before it hits your system.DOS allows any program to screw with the memory holding code/data for other programs and even the OS itself so it's easy for a misbehaving dos program to crash the system.
But I've done it. Usually because I'm running a Microsoft Program. They are riddled with holes and probably in many cases circumvent the safety features they put into the OS.With a proper windows NT platform on the other hand it's pretty hard to take down the system unless the faulty code is running in kernel mode (drivers)
Race ya... You write a program from scratch that accepts a string and 2 integers, outputs all 3 and the sum. Betcha who winsAs to Dos being easier to program in....again I disagree.....it's just a matter of spending a little time understanding how to program windows, then you have access to lot's of APIs and tools. Try code anything recent (say something web related, or ou want to use a current database) with DOS and your stuffed.
Seriously, if you wish to design a GUI I/O, yes there are lots of tools and API's. If I just want a basic program to display data, 'console mode' or 'command line' does make the programming easier and faster. And APIs are available in console mode so I still have system calls available without the headache of GIU hooks.
Definition: Politics -- Latin, from
poly meaning many and
tics meaning blood sucking parasites
-- Tom Smothers
You seem to be under the impression that the console apps you write on your window98 machine are dos based....
Unfortunately they are not. If you compile console apps with a modern compiler they are most likely full win32 apps with a console output - not dos in any way shape or form.
If you are using a dos compiler on a win32 platform then really you are still not using dos as your app will be run in a virtual machine, and all the dos & bios based interupt code will either be rejected or emuoated using APIS and services..........
>>But I've done it. Usually because I'm running a Microsoft Program. They are riddled with holes and probably in many cases circumvent the safety features they put into the OS.
Your running windows98...not an NT system....
Well.. Back to my question.
It's a quite advanced DOS program, with assembly linked(disable/enable interrupts), and reading from several comports.
I haven't developed it, i'm just maintaining/expanding it.
As for the malloc problem, i just wondered if anyone else had the same problem; i see that you don't, hence there's an error in the code somewhere.
This means that i have to scour the program once more for errors..
No I'm not. I know the difference. I started programming DOS in '82 so very aware of the differences.Originally posted by Fordy
You seem to be under the impression that the console apps you write on your window98 machine are dos based....
If you have a DOS program and w/out modifying any code, build it with VC++, I realize it's going to be a 32bit app and not runnable in DOS. That doesn't IMO change the fact it's a DOS program, per se. Putting a Corvette engine in a Pinto doesn't make it a Corvette, it's still a Pinto -- with guts.
If you're using an NT based system, DOS mode is emulated. A 95/98, it is a 32bit version of DOS I believe.
I honestly believe it's more semantics than anything else. If you build an originally DOS source in VC6, yes it can't run under true 16bit DOS but it also isn't a Windows app, either. The question then becomes is it truly a console app or a DOS app built and run in the console? Moot point probably, but fun to consider.
It's the same question I have with C/C++. Does the use of cin and cout alone make a program C++. I don't believe it does.
Yeah, except for my XP system. The programs are still riddled with holes. They just don't crash the system as often.>>But I've done it. Usually because I'm running a Microsoft Program. They are riddled with holes and probably in many cases circumvent the safety features they put into the OS.
Your running windows98...not an NT system....
Definition: Politics -- Latin, from
poly meaning many and
tics meaning blood sucking parasites
-- Tom Smothers
Interesting how we get off topic, eh?Originally posted by knutso
Well.. Back to my question.
It's a quite advanced DOS program, with assembly linked(disable/enable interrupts), and reading from several comports.
As I mentioned before, you'll need to post some code because we're shooting in the dark.
Definition: Politics -- Latin, from
poly meaning many and
tics meaning blood sucking parasites
-- Tom Smothers
Please post some code. We cannot help you unless you show us some code snippets. Enabling and disabling interrupts is not advanced and can be done in C, inline asm, or pure asm. There are 2 assembler mneumonics that enable and disable interrupts.
STI
CLI
At least I hope these are the ones, I'm a bit rusty on my assembler.
Kudos to Fordy.
Good to hear from you Bubba!
I don't think the assembly code is the problem. I'm no assembly programmer, could someone tell me if i figured it right:
The noop function just does nothing, what is the point of this function?
Code:__inton proc sti ret __inton endp __intoff proc pushf pop ax cli ret __intoff endp __intrst proc flag:word mov ax,flag push ax popf ret __intrst endp __nop proc ret __nop endp
so much hate.. lol
Some of this code does not look right but I will have to check my Intel manuals concerning the pushing and popping of the flags and when you need to do so. I cannot imagine why you would ever need to push any explicit return register onto the stack and I do not make it a practice to do so, but it can be done. AX is used for math operations (non-floating point) since it is the fastest register and is used for returning values back to C.Code:__inton proc sti ;enables interrupts ret ;return to caller __inton endp __intoff proc pushf ;push flags onto stack pop ax ;pop ax off stack cli ;disable interrupts ret ;return to caller __intoff endp __intrst proc flag:word mov ax,flag ;place flag(passed value) in ax push ax ;push ax(flag) onto stack popf ;pop flags off of stack ret ;return to caller __intrst endp __nop proc ret ;return to caller __nop endp
The __intrst function looks suspect. However it looks as though it is pushing previously stored flags back onto the stack. Again w/o looking at my manuals I'm sort of lost on the process.
The NOP function is useless.
Here is what I use the push and pop for most of the time.
This is 32-bit with TASM syntax. Push is used to save the ds register because programs - like the C compiler - use this register. So we save it on the stack, use it for our program, and then restore it when we are done with it so we don't crash the system.Code:__proc FastCopy32 ARGS source:DWORD,dest:DWORD,length:DWORD push ds ;save ds so we don't crash later mov eax,source mov ds,ax xor esi,esi mov eax,dest mov es,eax xor edi,edi mov ecx,length rep movsd pop ds ;restore ds ret __endp
