I have developed a graphic program on a desktop system. But when I tried to run it on the hp compaq laptop it's not getting executed. I developed it using Turbo C. Then i tried writing a simple graphic program in Turbo C on the laptop, but the problem I am getting is in 'initgraph' statement it is unable to detect the driver.
Can you please tell me what might be the problem?
Turbo-C, much like my first girlfriend, will always have a special place in my heart.
But its time to let her go. She's not the same girl you remember, and just cannot keep up with modern times. She may have been hip and cool at the time, but she can't handle modern trends at all. Even 32-bit memory is a real challenge for her. You're a better man now, and deserve a real woman. Go find yourself a good Visual Studio, or a nice GCC environment.
I'm not saying you have to forget Turbo-C. I know she was your first and will always be magical, but put her pictures in a shoebox, and don't take them out more than once a year. Its time to move on, buddy.
It sounds like it can't detect what kind of graphics card you have. Try setting the graphdriver parameter to either VGA or IBM8514.
In Turbo c goto options->Linker->Liabraries-> add Graphics Library.
It might help
I'm assuming that all the other prerequisites like linkers are satisfied.
Now, as we know the BGI folder is usually in the following path(i.e. if you've followed the default installation):
C:\TurboC++\disk\TurboC3\BGI
As you can see the BGI folder is inside "TurboC3" and not TC.
So the code you need to put in your program is as follows,
initgraph(&gd, &gm, "C:\\TurboC3\\BGI");
I hope this helps :) Happy graphics programming :D
you need to initialize the graphics function first.
below is the code to initialize.
int gd=DETECT,gm;
initgraph(&gd,&gm,"c:\\tc\\bgi");
this will initialize the graphics.
The Steps to make your TC able to run graphics program are as follows:
copy CGA.BGI and EGAVGA.BGI files from TC\BGI folder and paste them in TC\BIN directory.
Open TC by clicking on TC\BIN\TC.EXE.
Click on Options -> Linker -> Libraries .
Select the Graphics Library option and Press OK.
Now you can compile your graphics program with Zero Compilation Errors.
Thanks!
Related
I have a simple (extreme simple) real mode kernel written in assembly that I am trying to port to C as much as I can. In order to do that I am using OpenWatcom compiler for 16bit binary code.
In my file "os.c", if I write this line down it works:
char msg[50];
but if I do this:
char msg[50] = "hello";
it just does not work. Everytime I write a string it just get broken. I searched everywhere, tried a lot of nonsense stuff, and nothing.
Does anyone have a clue what it might be?
I can not post more than 2 links, so all 4 links needed is in pastebin. Thanks in advance.
Example: http://pastebin.com/xz96N91A
I have installed openwatcom so I could see what it gives. Apparently it's all a big mess, the data section seems to be applied in the middle of the code and such.
I recommend you instead create a COM format file. That at least appears to work.
I used the command wcl -s -zls -0 -q -ms -bcl=com os.c to create os.com which I used in place of your os.bin. I have also updated the far jump in the loader to jmp far 0x0040:0x0100 to account for the com entry point. Might need to set up some segment registers too, but for this test it worked without that.
I believe COM files had a limit of 64k, no idea if watcom enforces that. If it does, and you need more than 64k, you will have to investigate more.
Unless you are really forced to use real mode, you should probably not waste your time on it.
I learned to program with Pascal in high school, and more recently I decided to get out of the sandbox and try to figure out how my computer actually works. So I installed ubuntu on my iMac (i686) and started learning C, which seemed like a good way to get "under the hood."
One of the basic things I'm trying to figure out is where the kernel ends and the standard libraries begin. A book told me that the linux system calls (which I understand to be the interface between the kernel and the libraries) could be found in the header file unistd.h, so this seemed like a good place to start. But when I tried to find the header on my system (using locate unistd.h), I got this result:
/usr/include/unistd.h
/usr/include/asm-generic/unistd.h
/usr/include/i386-linux-gnu/asm/unistd.h
/usr/include/i386-linux-gnu/bits/unistd.h
/usr/include/i386-linux-gnu/sys/unistd.h
/usr/include/linux/unistd.h
/usr/lib/syslinux/com32/include/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/alpha/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/arm/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/avr32/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/blackfin/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/c6x/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/cris/include/arch-v10/arch/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/cris/include/arch-v32/arch/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/cris/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/frv/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/h8300/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/hexagon/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/ia64/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/m32r/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/m68k/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/microblaze/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/mips/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/mn10300/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/openrisc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/parisc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/powerpc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/s390/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/score/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/sh/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/sparc/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/tile/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/unicore32/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/x86/include/asm/ia32_unistd.h
/usr/src/linux-headers-3.5.0-27/arch/x86/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/arch/xtensa/include/asm/unistd.h
/usr/src/linux-headers-3.5.0-27/include/asm-generic/unistd.h
/usr/src/linux-headers-3.5.0-27/include/linux/unistd.h
/usr/src/linux-headers-3.5.0-27-generic/include/linux/unistd.h
Why the heck are there so many versions of this file--and other header files--in my system? Some of them seem to be for other CPUs (like sparc), so why did ubuntu bother to install them on my computer? And how does the all of this fit with what Eric Raymond calls the SPOT rule: "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." (The Art of Unix Programming, p. 91.)
Thanks in advance for any help. I'm happy to read big books if necessary.
I think these header files are directly from linux-3.5.0-27 source code. Ubuntu developers didn't know what kind of target they are dealing with. Maybe Intel x86/powerPC/ or even a mobile hand set(ARM), so they just copy all the head files and make a simple link.
I am not getting answers on the AVR Freaks forum and wonder if someone here could help me.
The answer might lie in this SO question, but I am not sure why it would be necessary.
Basically, I have my fist ever Atmel project (AVR studio 6, UC3 processor). The code compiles and links and I can load it to the Atmel board and step through in the debugger.
However, when I try to step over (or run until a breakpoint on the line after) a (valid) call to sprintf(), malloc() or memcpy() (there may be more, which I have not yet discovered), the IDE never returns to the next line of my code, just seeming to hang, or run forever.
[Note] Compiler optimization is off
Do I need to set some linker options (e.g link static (which I tried & it didn't help)? Or build with some library?
What confuses me is that the code compilers and links - what is being linked when I call these standard functions? If I need something else I would expect a compiler or linker error, but get none - so why won't my code run?
Sorry for such a stupid n00nb question, but it is my first micro-controller project.
I discovered that the CPU on my board is an Engineering Sample and not supported by Atmel Studio without a new io.h file.
I sort of figured that out from this question: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=106652
Sorry to have troubled you.
what is being linked when I call these standard functions?
The AVR-libc, the implementation of the C standard library ported to the AVR platform.
so why won't my code run?
Compiler errors and runtime errors are not even related. Both of these lines are valid C and they compile, however, on most systems, I'd expect them to dump core:
int x = 1 / 0;
*(int *)0 = 41;
So it might be either:
a bug in the standard library (very unlikely), or
a bug in the online debugger (very unlikely), or
maybe you just expect something that is not supposed to happen?
Instead of trying to step over, what happens if you set a breakpoint at next line after the line you want to step over?
Also, does the operation change if you turn off compiler optimization?
I'm trying to learn x86. I thought this would be quite easy to start with - i'll just compile a very small program basically containing nothing and see what the compiler gives me. The problem is that it gives me a ton of bloat. (This program cannot be run in dos-mode and so on) 25KB file containing an empty main() calling one empty function.
How do I compile my code without all this bloat? (and why is it there in the first place?)
Executable formats contain a bit more than just the raw machine code for the CPU to execute. If you want that then the only option is (I think) a DOS .com file which essentially is just a bunch of code loaded into a page and then jumped into. Some software (e.g. Volkov commander) made clever use of that format to deliver quite much in very little executable code.
Anyway, the PE format which Windows uses contains a few things that are specially laid out:
A DOS stub saying "This program cannot be run in DOS mode" which is what you stumbled over
several sections containing things like program code, global variables, etc. that are each handled differently by the executable loader in the operating system
some other things, like import tables
You may not need some of those, but a compiler usually doesn't know you're trying to create a tiny executable. Usually nowadays the overhead is negligible.
There is an article out there that strives to create the tiniest possible PE file, though.
You might get better result by digging up older compilers. If you want binaries that are very bare to the bone COM files are really that, so if you get hold of an old compiler that has support for generating COM binaries instead of EXE you should be set. There is a long list of free compilers at http://www.thefreecountry.com/compilers/cpp.shtml, I assume that Borland's Turbo C would be a good starting point.
The bloated module could be the loader (operating system required interface) attached by linker. Try adding a module with only something like:
void foo(){}
and see the disassembly (I assume that's the format the compiler 'gives you'). Of course the details vary much from operating systems and compilers. There are so many!
Back in the early 1990's, I used a library of routines in C called TCXL. I just wonder what ever happened to the guys who made that. I was about 25 years old the time, and learned C from a manual I printed out on my dot matrix printer. I think was using Turbo C, and I guess I downloaded TCXL from some bulletin board, or maybe Compuserve?
That library had cool routines to create "windows" for pop-ups and to create regions on the screen, as well has many other cool things that I can't fully recall. All this was in DOS of course.
http://cd.textfiles.com/swheaven1/UTILITY/
Mike Smedley, CXL's original author:
http://www.mikesmedley.com/