BGI problems

I have many programs written over many years using Borland graphics.
I have been working with different structures and patterns for weaving. Some of these programs are quite large with extensive graphics to show what the resulting fabric looks like. I do not wish to totally rewrite these programs when I decide to make a small change.
Since upgrading to Windows 10, & latest version of devC++, I have been unable to compile using graphics.h

I have changed from 64 bit to 32 bit
and added -lbgi -lgdi32 -lcomdlg32 -luuid -loleaut32 -lole32
I get an error message that says it cannot find lbgi
When searching my system, these files are not there.
When going to some web sites that claim a fix, my virus protection stops me.
Can anyone help me find these lib files?
Last edited on
Can anyone help me find these lib files?
Maybe send an email to @Duthomhas using the link at the bottom of the linked page:
https://cplusplus.com/user/Duthomhas/
I remember him mentioning BGI some time ago, he may be able to help.
BGI/WinBGI wasn't designed to work in a 64-bit app, only as a 32-bit app.

The library is so old the idea of a 64-bit operating system was a dream.
I know it requires 32 bit not 64 bit. I changed the compiler to 32 bit. I just need those five files to make it work. Otherwise, any minor change would require an extensive rewrite of these large programs. I would like to make minor changes as I think of them.
BGI/WinBGI wasn't designed to work in a 64-bit app, only as a 32-bit app.

Actually BGI was designed to work with 16 bit Dos.

What compiler/OS (exact versions please) were you using for the last successful compilation?

What is the exact version of devC++ you are currently using?

What is the actual "BGI" program/version are you trying to use?

I was using an earlier version of devC++ that was on my old Windows XP when it went south. I am fully aware that Borland was originally a DOS program as I was using it before Windows. In fact I was using Turbo Pascal and Turbo C on a CPM system when Bill Gates still had not shaved.
The devC++ I am currently using is the latest as I just downloaded it when my XP died and I replaced it with the Windows 10.
Actually, all I need are those five files to make it work.
Is anyone out there willing to let me know how to get them?

I know everyone out there wants me to move to the 21st century, but there is a huge library of programs that I tend to update on a regular basis. Or, at least, I would like to without having to rewrite them. At my age, a new graphics approach would be a huge learning curve.

I would also like help finding some easy to use graphics if no one can find those five files

And Yes, - - - I set the compiler to 32 bit from 64 bit I Know 32, 64
I really have only been doing computers since 1966 so I guess I am still a novice.
BGI may have been designed for DOS, but it can be thumped on to work with modern Windows, using Visual Studio as a 32-bit app.

https://home.cs.colorado.edu/~main/bgi/visual/

I've successfully upconverted the above VS 2010 sample solution to VS 2019 and VS 2022.
I will keep trying. It did not work with divC++ for me.
I may be doing something wrong or I am missing some simple thing that will make me feel stupid.
I really do not wish to put the effort into learning a new C compiler. divC is so easy to use.

Actually I found I only need the -lbgi

Last edited on
In fact I was using Turbo Pascal and Turbo C on a CPM system when Bill Gates still had not shaved


I fondly remember using Turbo Pascal on CP/M systems (Research Machine if I remember correctly). However I didn't know that Turbo C was available for CP/M - I thought it was MS_DOS only as it's first release was 1987? I think back then I used the Aztec C CP/M compiler.

I really liked Turbo Pascal (and later Delphi) and the Pascal language.

Ah - those were the good old days! :)
What version of DevC++ were you using when you created the original projects? What current fork of DevC++ are you using now?

Orwell's fork still works with Win10, though the embedded C++ compiler is about 8 years old.

[ETA]: Well, Dev-C++ 5.11 doesn't work with Win10 any more when creating 32-bit apps. Windows now blocks execution of the 32-bit app.

I tried to compile using Embarcadero's fork of Dev-C++, no joy though the compilation successfully completed.

Apparently the only viable (and easy) option left for WinBGI is to use Visual Studio. I know that works. I was able to use the VS2010 sample, letting Visual Studio upgrade the project/solution.
https://home.cs.colorado.edu/~main/bgi/visual/

All the WinBGI source files needed are included, and I was able to get the Dev-C++ sample to work.
https://home.cs.colorado.edu/~main/bgi/dev-c++/

Substituted the contents of main into the VS WinMain, and nice purty WinBGI window with a circle and a title bar of "First Sample" was displayed.

Seriously consider taking some time and make an effort to install Visual Studio 2019 or 2022 (2022 recommended) so you can mash your old Dev-C++ projects over to MSVC.

VS and Windows were designed to work together, playing nice. Dev-C++ even with the newer forks are antiques.
Last edited on
I started using devC on a very early version, when I first heard of it.
Then I kept upgrading till last summer when my XP died.
The programs compiled correctly until then, but then Windows 10.
I feel like a rat in a maze.
Once I find my way to the cheese, some Microsoft programmer moves it.

I used Turbo Pascal on a CPM Kaypro II.
My mistake, that is right about Turbo C. That was after the PC came out.

Just because something is old, that is not the reason to throw them out.
And talking about antiques, that is me.

I installed VS. I guess learning that will help prevent Alzheimers.

When I started with IBM in 1966 I was assigned to a new concept where one computer could communicate with another remotely. They were really not sure that that would have much value except for within a factory at that time. Then they discovered it could be used over a phone line.
For those who are interested in antiques, I actually worked on a vacuum tube computer.
Walk through an aisle between walls of vacuum tubes and look for the one with the heater out.

I also worked for Xerox Data Systems when their computers were the only thing NASA was using. And, there was a Xerox Sigma 2 (or SDS Sigma 2) at the bottom of every missile site.
Xerox actually invented what eventually evolved into Windows.
It took Microsoft programmers a while before they became aware of stack/heap collision.

Most of my experience was with real time process control scientific computers.
Just because something is old, that is not the reason to throw them out.

Within reason, of course. That meatloaf in the fridge from 2 months ago is a goner.
Using these old libraries is fine when you have reams of legacy code that needs it and want to eek out just a few more years before a rewrite. Been there, done that. I had to use visual studio 6.0 for a good decade running, until we finally hit a wall and got the boss to buy that first .net version or maybe the one right before that, I forget now.

Consider though that a lot of new tools are much better than what we had in the 80s and 90s.
If you really, really get pushed up against the wall, what you do is not rewrite all that old code. Instead, take a library that is close already and make the functions that you need (there are probably around 20 major ones and maybe another 20 minor ones (major being stuff like setting the resolution, minor being draw a square or circle etc at a location). I doubt it would take a pro a full month to recreate what they needed with wrappers to a totally different library. No reason for it if you can get it working, but I strongly advise that approach over rewriting the source. Nothing should change in the source, it just links to smoke and mirrors that do what you needed via wrappers, and the project file or whatever build with the new stuff instead. The good news is that if you end up there, you can tap the new tools in the new graphics library as well, alongside and fully integrated with the fake BGI.
Last edited on
The Visual Studio WinBGI sample illustrates how to wrap DOS BGI in a WinAPI framework, using WinMain instead of main.

Since the sample has all the needed source files, no already compiled library files, gives a hint using Dev-C++ might be possible with a bit of work.

Just because something is old, that is not the reason to throw them out.

The time and costs of maintaining a legacy system can eventually become impossible to justify. Keeping something alive just because it is old and familiar hides the potential advantages of updating to modern tools and practices.

The VS BGI framework has already been done, crafting it for Dev-C++ requires more work. Work that may prove futile, there are no guarantees it will work with Dev-C++.
I do believe in upgrading.
I moved from huge room filling computers to one I could take on an airplane.
Now I have in my pocket something that is more powerful.

I suppose I will have to learn VS, but this rat in a maze does not like his cheese moved.
Once I learn VS and develop some skill, somebody will move the cheese again.
I guess I am just lazy and do not wish to put the effort into learning something new.

I agree about that old meatloaf. And, yes, I agree, that is not the only thing.

With my programs, all I need to do is to be able to place colored dots in specific locations many times.
If I can do that, I can write my own graphics functions, at least the ones I use.
I am going to think about that.
However, I think -lbgi will link what I need saving a lot of effort.

And, I do like the devC++ editor and user interface.
I guess this old dog needs to learn a few new tricks.
you can use devC editor and VC compiler if you really hate the VS editor or fat IDE.

but once you use the visual debugger, you may find yourself hooked.
I use notepad++ on the side, when VS wants to be annoying about something. VS is smart and will handle it if your code is edited by something else, even when it has the same files open.

Good luck with it! You are not alone I did the same thing a few years back for a co-worker (wrapped up a function to put one pixel at a location) who didn't want to deal with the complex modern libraries, and a guy on here has been developing a tool that more or less does exactly that as well. Sometimes, its all you need, and the library writers have partially forgotten that.
Topic archived. No new replies allowed.