last version of C::B Advanced

Discuss anything not covered by any of the other categories.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

forgot angle for the opengl libraries, allthough angle actually uses both d3d and opengl so its a bit misleading.

codeblocks is the final stable 12 version now, later svn builds can be made if requested. just keep in mind that these might be unstable.

Also a few things to be aware of since i use openjade for document creation be sure to not try and update the docbook packages
from the msys2 site, if you do you will break it!!! so dont do it.

Latest mingw64 api now supports ucrt, and the build system defaults to win7 compatibility now, and not like previously winxp.
build errors might be caused by this, in that case you will need to set the api version to 0x501.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Not much new on the front of my old Msys2 MinGW64 project, but i have something that might be of use to people still dabbling in DOS. For some time i been fixing up bugs in digital mars, and while it could build the crt for windows projects
it failed when trying to do the same with the crt libs for dos (especially those that relied on dos extenders). The reason for this was that Digital Mars had some changes in the later patches which added native C++ new and delete as well as C++ exception handling. The old dos crt was newer setup to work with C++ exception handling at all and so it failed to compile.
Untill now atleast... I finally managed to get the full crt to build and it now supports C++ exceptions.

The crt was build and linked to a later version of stlport than the one comming with Digital Mars as standard (this version is also included, and its prefered to built against it if doing C++ builds due to Digital Mars old api having very limited STL container support without it). Stlsoft is also included.

Another rather irritating problem that kept creeping up was that the crt relied on an old not very well documented masm compiler, the maintainer had created a tool to wrap masm 6.0 for compatibility, but it did not work correctly for the afforementioned dos components :S so i been on a wild goosechase to hunt down this illusive masm version which i finally found hidden in some obscure NT3 - 4 Developer tools. Also quite a few makefiles from the crt had oversights like missing semicolons at the end of some statements needing them, so it took me allmost a year to get everything i needed to build everything.

This compiler was originally based on symantec C++ (not a joke :) symantec actually made compilers once, and they where actually quite good at that time), but since it was commercial he could not offer the compiler for free back then, so he sold licenses for a modest fee for those who needed a blazing fast DOS/Windows compiler.
the maintainer (which btw was the original creator of symantec C++) has since uploaded the full suite under the boost license, cause he now owns the rights to it.

And no the project is far from dead, However not much work goes into Digital Mars anymore since walther Bright (The Maintainer) is busy with D-lang which he invented ;).

For windows projects, the compiler can make most stuff as long as it does not rely on modern apis like C99 or C++11. The SDK that comes with it by default is based on a rather old windows SDK from around the time of NT3 - 4 so keep that in mind. It also has an IDE which resembles the old borland IDE with floating windows. Its nothing fancy but its enough for small projects.

The compiler itself was originally named SC but walther bright has since replaced it for most things with the much newer DMC compiler, which is part of D-lang also (infact the latest version on git is built allmost entirely in D).
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

after a few more fixes stlport now builds cleanly with dm again.
new / delete + exception support was added after the stlport port, and seems it was not tested if it was still compatible.
It was not because the code for new + delete was actually taken from stlport so it ended throwing an error about these because they where allready defined. I changed stlport source so that it disregards new include and instead uses the old new.h include.

This worked beautifully :) and also means we can use it without stlport in case the dos api croaks.
the old hp stl does not have this bug since it does not have a new header at all, so it might actually be the better choice
for older sources.

Tested the newly built stlport with dos and it works like a charm :) so seems there wasno case for worry after all.

one snag i ran into was that dm uses the last iteration of the dosx extender.
The api libraries are included and working, but the actual dosextender is impossible to find anymore.
so if anyone got a copy of the last one (named xm something) i would gladly include it in the package.

Oh and forgot to mention, digital mars is 100% standalone, you can even compile from an usb stick :)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

found it, its called x32-vm had to grab the executables from kitchensink :) works like a charm to.

Next project might see c++14 support, by using libcxx from orangec. will need to change a few things in the compiler so that it can support it. changes to both optlink and dmc will be nessesary. Also pondering if i should add coff support since atm digital mars only
supports omf, much like borland.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

updated digital mars with the latest stlport 5.2.1.
Also exposed a few system calls to the internal crt libraries that where missing and caused allegro to fail building.

rewrote new and new.h, still uses much the same code as stlport but the old version had std calls in new.h !!! :shock: this caused stlport to bank when building because it exposed the C versions on top of the C++ classes.

new.h was deprecated and now links to new which contains both the malloc based C versions and the class based C++ ones.

added allegro development libraries built on the new version.
added different assemblers masm fasm wasm tasm nasm and yasm do do de dooh.
the masm and masm386 version 5.NT.02 included is needed while building the crt, no newer or older version works (SO DONT DELETE IT!).

stlport-5.2.1 normally required an msys or cygwin environment to build the dmc libraries which kinda sucked, so i ported it to use digital mars own tools.

the compiler is fully standalone as said and can be used from an usb stick if need be.
It can build NT WINDOWS DOS OS/2 and a few UNIX sources.

Also bear in mind that the linker only accepts OMF format libraries, so if you plan on doing development with the platform sdk for msvc 6 or newer directx sdk then you need to convert the libraries to omf beforehand.
there are 2 tools for that, one is coff2omf but that one requires that you have microsoft visual studio 6.0 because it needs lib and link.exe to do the conversion, or coffimplib which only works for import libraries.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

last update before release.

i ported the xp platform sdk to digital mars and it works for building both stlport and the crt.
minor quirk stlport needs to have a define set in userconfig.h for the new platform sdk, also do not try to recompile the idl's with digital mars midl (it is to old) if you need to recompile the idl's use midl from a later version of platform sdk.
it also breaks some of the samples because they are incompatible with the new sdk (relax typechecking will not allow them to be built either).

the good stuff -> you can now build modern applications with digital mars :) the previous sdk only supported up to NT 4.0 the new version supports up to windows xp.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

a little tidbit of some of my modifications to digital mars new and delete

Code: Select all

/* Copyright (C) 1986-2001 by Digital Mars. $Revision: 1.1.1.1 $ */
/* Modified by revelator 2019 adding working exception support and placement operators */
#if __SC__ || __DMC__ || __RCC__
#pragma once
#endif

#ifndef __NEW
#define __NEW 1

#if !defined(__cplusplus)
#error Use C++ compiler for std::new
#endif

#if !defined(_SIZE_T_DEFINED)
# if _M_AMD64
	typedef unsigned long long size_t;
# else
	typedef unsigned int size_t;
# endif
# define _SIZE_T_DEFINED
#endif

/* std based new and delete only work on windows */
#if (_WIN32)

#include <exception>

typedef int( __cdecl *_PNH ) ( size_t );		        //for Microsoft compatibility
typedef void( *PFVV ) ();						//as defined in ARM

_PNH __cdecl _set_new_handler( _PNH );	       //for Microsoft compatibility
PFVV set_new_handler( PFVV ); 			       //as defined in ARM

namespace std
{
    class bad_alloc : public exception
    {
	public:
		bad_alloc() throw() : exception() { ; }
		bad_alloc( const bad_alloc& ) throw() { ; }
		bad_alloc& operator=( const bad_alloc& _rhs ) throw()
		{
			/* rogue wave enable exceptions */
			exception::operator=( _rhs );
			return *this;
		}
		virtual ~bad_alloc() throw();
		virtual const char* what() const throw();
    };
	class nothrow_t { }; 
        extern const nothrow_t __cdecl nothrow;
	typedef void ( __cdecl *new_handler )();
	new_handler __cdecl set_new_handler( new_handler new_p ) throw();

// Implicitly declared ones (std)
#if !defined(__NEW_DEFINED)
#define __NEW_DEFINED 1
	// Prototypes for the standard global new & delete operators
	void *__cdecl operator new (size_t);
	void __cdecl operator delete (void *);
	
	// non throwing types
	void *__cdecl operator new ( size_t, const nothrow_t& ) throw();
	void __cdecl operator delete ( void *, const nothrow_t& ) throw();

#if _ENABLE_ARRAYNEW
	// Prototypes for the standard array global new & delete operators
	void *__cdecl operator new[] (size_t);
	void __cdecl operator delete[] (void *);

	// non throwing types
	void *__cdecl operator new[] ( size_t, const nothrow_t& ) throw();
	void __cdecl operator delete[] ( void *, const nothrow_t& ) throw();

#endif
#endif
}

/* guarded in case of flunk from stlport */
#if !defined(__PLACEMENT_NEW_DEFINED)
#define __PLACEMENT_NEW_DEFINED 1
inline void *__cdecl operator new ( size_t, void *p ) throw() { return (p); }
inline void __cdecl operator delete ( void *, void * ) throw() { return; /* noop */ }

#if _ENABLE_ARRAYNEW
inline void *__cdecl operator new[] ( size_t, void *p ) throw() { return (p); }
inline void __cdecl operator delete[] ( void *, void * ) throw() { return; /* noop */ }

#endif
#endif

#endif /* _WIN32 */

#endif /* __NEW */

Old one had non working exceptions largely because the old implementation was incomplete and more or less just used nothrow.
The new version has working exceptions based on the rogue wave code and also correctly implements placement code for new and delete.

new.h also still exists as a fallback for code that cannot use the std functions, sadly large parts of the handler is still in C and used in both as splitting them up would require an enormous ammount of hacks to support old dos code which has no notion of std at all (hence the _WIN32 guard).

Oh and one small FFS!!! i tried converting the platform sdk libraries from the win 7 sdk, but sadly one library refuses to be converted to OMF (fileextd.lib) so untill i can resolve this XP support is as high as you get.

Lot more work had to go in before i could build the last released stlport 5.2.1 and still be able to build the CRT, i also tried replacing the old C/C++ compiler with a newer version from digital mars D but it seems to have problems with the SEH code so i shelved it for now.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Digital Mars is pretty usable now and not just for DOS coders :)
Tools build against the ported api work even on win10 now.
The ide needs some TLC though, it runs in win10 but shows all wrong because of win10 high dpi scaling, so you have to set a few compatibility flags to make it work correctly.

I also created two clang packages that can be used with Msys2's pacman command makepkg-clang.
These builds are mingw compatible (eg. they can use mingw libraries for linking but not the other way around).
The cause of this is the way clangs lld linker works, it uses weak symbols in the libraries which was newer supported by the windows binutils :(.
But the other way around it works, and it will in some cases be nessesary to use a mingw built library because clangs tools are not 100% compatible with libtool.

These builds use libc++ libc++abi and libunwind as well as compiler-rt, and builds against the mingw-w64 ucrt port(so you pretty much need atleast win7 for things to run,
allthough i hear that XP might also be supported if you yank in the ucrt runtime dlls).
Win2k and older do not work though (tested and the compiler crashes).
I have built a few packages with it, like iconv gettext openssl and a few compression and image libraries, and they all work like a charm :)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

https://sourceforge.net/projects/cbadva ... z/download
https://sourceforge.net/projects/cbadva ... z/download

The two forementioned clang packages for use with Msys2.

Or if you prefer you can also use them with Msvc :)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

created two new builds of the mingw64 based clang compilers.

These now default to the msvcrt runtime so should work with older windows as well :)

Both these and the last packages have been crossbuilt using win 10 wsl ubuntu.

Next version will also support the z3 constraint tool, as the internal sanitizers dont work on 32 bit builds yet (not ported), z3 is a microsoft tool to quench clang sometime throwing a fit against perfectly legal code.

Ill upload the new builds soon.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Digital Mars 8.5.8

https://sourceforge.net/projects/cbadva ... z/download

old and new sdk included in the sdks folder. Do not overwrite include, if you made changes backup the folders and then delete them before changing.
New sdk supports win9x -> XP old one supports dos -> NT4.
stlport upped to latest 5.21 version.
masm 5.02 NT special version (needed when rebuilding the crt) included, also the missing x32-vm dos extender was added from kitchensink.
Perl scripting is supported.
Unix tools via busybox, these can be enabled in setvars.bat, carefull though, some sources do not like these, while others will need them.
Updated linker with the latest fixes for win 8 -> 10.
Compatibility manifests added for IDDE and a few build tools to avoid to many UAC pop ups. Also the manifest for IDDE takes care of the high DPI scaling problem in win 7 and later versions.
dm.exe Shell script launcher for win 7 -> 10 - 64 bit, earlier windows versions should handle the setvars.bat file just fine, autosets admin for console builds.

To use from an usb stick launch dm.exe on 64 bit OS like win 7 -> 10 or setvars.bat on earlier versions, then if you want to use the IDDE issue scw32 on the commandline and hit enter to open the IDE. Console builds follow the standards of borland C++ compilers with the difference that the configuration scripts reside in one file called sc.ini. You can add additional include or library paths here, as well as other commands.

On win9x/DOS the IDDE command is scw.

If you find the IDDE to be to awkward you can also use codeblocks as the IDE, in that case unzip the archive to C:\ and open codeblocks to setup the compiler.

The new STLPort supports unicode, so even japanese or chinese should work.

I also included the renowned optasm assembler and optlib librarian which are some of the fastest for DOS building, optlink is included by default.

If you wish to rebuild the crt use setvars.bat or the launcher and cd into src/build then do a buildlib followed by rtlclean. The libraries will have uppercase names so lowercase them manually or with a tool like bulkrenamer. There is no need to rebuild the crt unless you made changes to it so dont just do it for fun.
You can also rebuild stlport in src/stlport/src by issuing smake -f dm.mak and then copying the libraries to lib and the dll's to bin but again unless you made changes dont, the compiler works as it should as is.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Just a cautionary warning with Digital Mars.

The old sc.exe compiler from the symantec days still exists in the build tree, but later versions of windows have an sc.exe on path that has nothing to do with a compiler.
If you run into problems compiling some old source on later windows this is most likely the culprit, and you will need to modify your makefiles so that the C or C++ compiler uses dmc.exe
instead. Else make sure that the compiler is first on path, so that sc from windows does not interfere.

Forgot to mention that the included directx version was upped to directx 7, if you need later directx you will have to convert the libraries to omf.
There are tools in the Digital Mars compiler for this like coff2omf, but that one needs a fairly old ms linker.exe and lib.exe from visual studio 6 or 7.
Or coffimplib but this one can only convert libraries that have corresponding dll's. I also included uconvert which can even convert coff objects to omf, but read the help file for how to use it.
Win10 also does not support the old help format, so i included wines win32hlp.exe in the help folder, you can open the help files with that or take ownership of the win32hlp.exe in C:\Windows
and overwrite it with the wine version. If you decide to overwrite the win32hlp.exe in C:\Windows make sure to also copy the libwine.dll to C:\Windows as it relies on that.
The benefit of this is that you can now open old help files like you did in previous versions of windows.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

changed winhlp32 to the one from reactos (no more dependency on libvine), still works great with win10 :)

new platform sdk was put on the backburner for now because of some problems that cropped up.
old sdk was updated somewhat to alleviate the lack of some of the things from the above (gdiplus and dx7 added).
updated optlink and make to latest from dlang (these still handle C/C++ no worries).
reverted stlport 5.21 to an earlier version 5.14 since it turned out that the latest one has some problems with digital mars.
fixed stlport build scripts for digital mars, stlport uses a posix echo which can skip newlines, unfortunatly unless you had something like say msys it was a pita to configure it.
so i rewrote the configuration scripts to use a posix echo from the old unxtools package renamed to write.exe (so that it does not collide with the system echo) which had that capability.
carefully examined the stlport configuration headers for digital mars, and made appropriate changes since newer versions of the compiler now include some standard libraries by default.

rebuilt the MFC sdk with the newer compilers (that was hell let me tell you yuuuuuck...)
it took some pretty heavy handed rewriting of the old MFC42 classes that the newer dmc compiler no longer understood :/ but it's done now.

forced inclusion of the uuid libraries into the crt since i noticed that many samples failed to build due to missing exports like _UUID_SomeStuff.
I have a hunch that the newer dmc compiler was added mostly as a means to ease transition to dlang since it supports much newer apis than the ones that come with the old digital mars.
Sadly this also breaks a lot of compatibility with older sources which will have to be rewritten.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Since im now doing active work on msys2 i can tell that we added the clang compilers from martin storsjo and that they now build natively using msys2 as shell. these are now less geared towards cross compiling but more toward native windows builds, they are also able to build a huge set of the packages that the gcc based mingw-w64 compilers can.

noteworthy you can actually build dxvk and vkd3d12 with them, which might be interresting to people wanting to toy with trying to run directx stuff in vulkan, tested with horizon zero dawn (works) it does shave a little of the fps though so i do not recommend playing on the highest settings.

codeblocks has also been updated but not yet released anywhere since it is in beta atm. if you want to try it out pm me and ill get you a copy which is setup to use most compilers shipping with msys2.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

hmm a recent change has reverted the path behaviour of the msys2 mingw-w64 compilers to the standard used by mingw.org while most things still builds with this change i discovered that atleast python 2 and 3 are non to happy with this as they expect the system headers to be located in the <arch>-w64-mingw<bit> paths and not in the global sysroot. guess we will see a lot of patching comming up due to this change. not even sure why it was changed other than to follow the fedora model since it worked fine before also.
Productivity is a state of mind.
Post Reply