I tried to build OWLNext 6.35 using the with free Embarcadero C++ compiler 10.1 Berlin.
In OWLMaker I selected C++Builder 10.1, but this doesn't seem to be the right choice.
The build fails, probably because of the command C:\BCC101\bin\rsvars.bat: There is no rsvars.bat file.
Is there a way to build without this file?
Erwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Erwin and Sebastian, I did some work on this a couple of weeks ago. Take a look at [feature-requests:#100].
Note that the toolset for C++Builder/RAD Studio 10.1 Berlin in OWLMaker makes use of MSBuild and the MSBuild project file "source/owlcore/CBXE3/owl.cbproj". Unfortunately, this cannot be used for the Free C++ Compiler, since it does not come with these build tools. So I started reworking the old "bc.mak", changing it to use BCC32C rather than the old BCC32, etc. See my attachments to the ticket.
However, work remains to be done. Since the Windows SDK is not part of the Free C++ Compiler setup, this has to be installed separately, but somehow, and preferably seamlessly, picked up by the make file, e.g. via some environment variable. Perhaps the SDK already defines an environment variable that can be assumed to exist after installation and thus used in the "bc.mak" make file to pick up the SDK location.
Edit: It seems I overlooked the Windows SDK library files, located under "lib/win32c/release/psdk" in the Free C++ Compiler setup. So, the setup on its own may be sufficient to build OWLNext.
I have now added the path to the Windows SDK libraries to my reworked "bc.mak" make file, and it now builds just fine with the Free C++ Compiler setup.
See [feature-requests:#100] for the updated patch. Here is the output from a make test, run from a Command Prompt:
C:\OWLNext\trunk\source\owlcore>make -f bc.mak OWLVER=7.0.0 COMPVER=720 DEBUG=1 MT=1
MAKE Version 5.41 Copyright (c) 1987, 2014 Embarcadero Technologies, Inc.
SubWCRev: 'C:\OWLNext\trunk'
Last committed at revision 3485
Mixed revision range 3420:3485
Local modifications found
Unversioned items found
Version header is up to date.
LIBTARGET = ..\..\lib\owl-7.0.0-c720-x86-dt.lib
BCCVER = 720
OWL_VERSION = 7.0.0
Embarcadero C++ 7.20 for Win32 Copyright (c) 2012-2016 Embarcadero Technologies, Inc.
animctrl.cpp:
appdict.cpp:
applicat.cpp:
[...]
initdll.cpp:
winmain.cpp:
main.cpp:
"C:\PROGRA~2\EMBARC~1\BCC101\bin\..\bin\tlib" /P2048 "..\..\lib\owl-7.0.0-c720-x86-dt.lib" @MAKE0001.@@@
TLIB 6.4 Copyright (c) 1987-2014 Embarcadero Technologies, Inc.
+"..\..\obj\owl-c720-x86-dt\animctrl.obj" [...]
thanks for your help.
What I did so far:
a) Created 'rsvars.bat' to add bcc101\bin to %PATH%
b) Applied patch "Support for the Embarcadero Free C++ Compiler.patch"
This worked for bc.bat, but not for "source/owlcore/VS/OWLNext.vcxproj" since there is no source/VS path in my 6.35 installation.
I didn't patch and build OWLMaker.
When running OWLMaker now, I get errors like this:
"Error bc.mak 1757: Too many rules for target 'Init'"
for 6 targets before the build stops.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. All you need with the new "bc.mak" provided by my patch is to have "BCC101\bin" in your path as you issue the make command on a Command Prompt, unless you specify the full path to make of course (which is what OWLMaker does, by the way).
This worked for bc.bat, but not for "source/owlcore/VS/OWLNext.vcxproj"
The VS project is set up to use the Microsoft C++ compiler. To make it use the Embarcadero Free C++ Compiler, you would have to do major surgery, and you would gain little.
However, I guess you are just experimenting with OWLMaker, trying to force it to use the Free C++ Compiler. This will not work. Instead, apply my OWLMaker patch. You will then get the Free C++ Compiler in the list of toolset options, but currently only for OWLNext 7 (trunk).
To enable the Free C++ Compiler toolset in OWLMaker for OWLNext 6.35/6.43, the OWLMaker patch will have to be updated. See "OWLMaker/Toolset.h", class TToolsetBCC32C101, member function SupportsOWLNextVersion. This function needs to be updated to make it work with 6.35 (and 6.43).
To add official support for the Free C++ Compiler in OWLNext, someone have to be willing to create similar make files for OCFNext and the other extension libraries as well. Note that, to backport support to 6.35/6.43, the new make files will need a new name, e.g. "fc.mak", since these versions already have "bc.mak" for the classic BCC32 compiler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am also upgrading to Berlin 10.1. I noticed in a reply to Vidar that you were able to build a new OWLNext app with it.
How did you build your app? Following the instructions in the OWL Installation Guide, I created an OWL project and built my app, but when I execute it, I get a console window apperaing along side it. How do I get rid of this console window?
By the way, I was unable to follow the instructions exactly because it is not possible to uncheck the Console checkbox in 10.1.
Marvin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Sebastian, note that we already support C++Builder/RAD Studio 10.1 Berlin for OWLNext 6.35, 6.43 and 7, including OCFNext and the other extension libraries. For this product, there is support for the new Clang-based compilers, including 32-bit (BCC32C) and 64-bit (BCC64) support in OWLNext 6.43 and 7. In version 6.35, there is only support for the classic 32-bit compiler (BCC32).
Although OCFNext compiles in all these versions and for all these compilers, I have not done any further testing. I only do build tests for OCFNext, and regressions in run-time behaviour may have gone undetected. So I welcome review of OCFNext.
As for the extension libraries, OWLExt and CoolPrj, I use them for OWLMaker, but that is so far my testing goes.
If you want to add make files for the Embarcadero Free C++ Compiler in OCFNext and the extension libraries, I will review the changes and help with adding support in OWLMaker. If there is demand, I can also backport the changes to 6.35 and 6.43 for inclusion in a maintenance release.
Last edit: Vidar Hasfjord 2016-09-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Vidar,
after recalling forgotten knowledge on the make syntax I füond the reason for the make errors I got: The patch didn't replace the contents of bc.mak but added the the patch contents. (Maybe I missed something on my first explicit patch use, I executed "patch -p0 patchfile".)
After removing the old contents, the compile started, however with new errors:
e:\OWL635\INCLUDE\owl/control.h:98:3: error: no matching function found in local scope
DECLARE_STREAMABLE_OWL(TControl, 2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1525:5: note: expanded from macro
'DECLARE_STREAMABLE_OWL'
DECLARE_STREAMABLES( cls, ver )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1483:5: note: expanded from macro
'DECLARE_STREAMABLES'
DECLARE_STREAMERS(cls, ver ); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1289:22: note: expanded from macro
'DECLARE_STREAMERS'
friend void ::owl:: READVIRTUALBASE( cls );\
^~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1252:31: note: expanded from macro
'READVIRTUALBASE'
. #define READVIRTUALBASE(cls) ReadVirtualBase( cls *, ::owl::ipstream& )
Any idea what is wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure if related. I've installed C++10.1 on my notebook and when trying to build using OWLMaker I've noticed that the installation doesn't install by default Boost. At first time i've copied the version 1.39 from C++Builder XE but it didnt worked. I've used the GetIt Plugin manager and after that I was able to build OWLNext.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I should have stated that the patch is applicable to the trunk (version 7), and is probably easiest to apply using the TortoiseSVN Apply Patch command. To backport the patch to 6.35, more work needs to be done. In particular, the makefile will need a different name, e.g "fc.mak", as I mentioned in one of my earlier replies.
Also, the 6.35 code has not been ported to compile with the Clang-based compilers. You may need to make further changes to the code. You can search through the log for 6.43 to see what changes have been made in this regard, and you can make diffs between the versions to inspect the effective differences (the TortoiseSVN tools such as the Repository Browser is handy for stuff like this).
PS. Why do you need support for BCC32C in 6.35? Although I see many are sticking with 6.35, this version is just meant as a stepping stone to 6.43. If there are issues stopping you from moving to 6.43, I suggest putting the effort into removing these instead.
Last edit: Vidar Hasfjord 2016-09-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
... with 6.35, this version is just meant as a stepping stone to 6.42.
This is what I planned to do now.
Actually I'm using 6.21. My idea was to switch to an up-to-date compiler in order to bring my application code to an acceptable state. Since I use BCC5.5 via a makefile, this step was quite easy to achive with BCC101. The plan was also to stay with 6.35 for this step for testing changes so far.
Then, migration to 6.4x should be much easier, I guessed.
But as the situation turned out to be, it seems that I have to change my strategy.
I could either switch to VS (which I have only little experience with) and 6.35, then migrate to 6.4x.
Or, I try to do both steps (BCC55 --> BCC101 and 6.21 --> 6.4x) together and switch to VS somewhen in future.
What do you think might be easier?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We switched from OWL 5 to OWLNext 6.20 8 years ago using the C++Builder 2007.
The modifications in our code were minimal and by some time we used dual compile to keep working in BC5 and C++Builder2007. Most of those modifications were for OWL 2.x code and some signatures in members functions like GetClassName();
By using:
we managed to mantain our code compatible for both compilers.
After that we moved to OWLNext 6.30 first with C++Builder 2009 and later with C++Builder XE.
I've just installed C++Builder 10.1 this saturday, builded OWLNext 6.45 and moved a first project to the new version of compiler/library. We even managed to build our first 64bit OWLNext app. The new C++/Clang compiler it's really beatifull and very valuable.
The typical modifications to move to 6.35/6.4x is to add:
#if OWLVersion<0x0632
namespace owl = OWL;
#endif
in our headers and at the very first of our source code:
usingnamespaceowl;
I know that some issues will appear, but so far the new C++Builder 10.1 it looks really good.
Last edit: Sebastian Ledesma 2016-09-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, I think you need to decide on your modern development tools. Depending on your choice, then there are two ways to proceed.
If you select Visual Studio or Embarcadero C++Builder/RAD Studio, the path forward is easy. Since you have updated your code to 6.35 already with BC++ 5.5, you can switch to any of these by just recompiling (barring other unforseen compiler differences). Then move to 6.43.
If you decide to stick with the Embarcadero Free C++ Compiler (BCC32C) for further maintenance of your software, then I guess the direct jump to 6.43 is easier than trying to update 6.35 for BCC32C.
If you are looking for the free route, note that Visual Studio Community Edition is free for open-source and small business. This is the way I went with my software. I recommend it as a good fit for anyone used to the Borland C++ IDE (integrated editor, debugger and resource editor). Try it out. It is freely available to download.
You can also freely check out the Embarcadero option by downloading a time-limited trial.
Hope that helps.
Last edit: Vidar Hasfjord 2016-09-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just installed C++Builder 10.1 this saturday, builded OWLNext 6.45 and moved a first project to the new version of compiler/library. We even managed to build our first 64bit OWLNext app.
Good to hear!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How did you build your app? I just installed the Berlin 10.1 compiler and moved my code over. Following the instructions in the OWL Installation Guide, I created an OWL project and built my app, but when I execute it, I get a console window apperaing along side it. How do I get rid of this console window?
Marvin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not a C++Builder user. However, in Visual Studio, the setting "Configuration Properties | Linker | System | SubSystem" controls whether or not to build a console application. For a non-console OWLNext GUI application this setting is set to "Windows (/SUBSYSTEM:WINDOWS)".
Last edit: Vidar Hasfjord 2016-12-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, I discovered an easier, but similar, method. I created a new project as indicated in the OWL Installation instructions. I then openned that .cbproj file and made 2 simple changes:
<AppType>Console</AppType> to
<AppType>Application</AppType>
and
<ProjectType>CppConsoleApplication</ProjectType> to
<ProjectType>CppGuiApplication</ProjectType>
Marvin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I switched back to BCC5.5 now to complete the migration to 6.35.
One unsolved issue is my use of TSystem::IsWin95() which I need to continue for some time. In 6.35 it is only available in OWL5 compatibility mode. I don't know what side effects will appear when I use it, so I better would create some workaround for this special case, right?
Or what would be your suggetion?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Erwin, TSystem::IsWin95 is just a wrapper for Windows API function GetVersionEx which is deprecated and may no longer work as you expect:
GetVersionEx may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper functions.
Henceforth, OWLNext will no longer use this function, and there will be some changes in TSystem. See [bugs:#323], "TSystem returns incorrect information".
Hi,
I tried to build OWLNext 6.35 using the with free Embarcadero C++ compiler 10.1 Berlin.
In OWLMaker I selected C++Builder 10.1, but this doesn't seem to be the right choice.
The build fails, probably because of the command C:\BCC101\bin\rsvars.bat: There is no rsvars.bat file.
Is there a way to build without this file?
Erwin
Hi:
Heres is the content of my 'rsvars.bat', you must adapt it to your installation:
Erwin and Sebastian, I did some work on this a couple of weeks ago. Take a look at [feature-requests:#100].
Note that the toolset for C++Builder/RAD Studio 10.1 Berlin in OWLMaker makes use of MSBuild and the MSBuild project file "source/owlcore/CBXE3/owl.cbproj". Unfortunately, this cannot be used for the Free C++ Compiler, since it does not come with these build tools. So I started reworking the old "bc.mak", changing it to use BCC32C rather than the old BCC32, etc. See my attachments to the ticket.
However, work remains to be done.
Since the Windows SDK is not part of the Free C++ Compiler setup, this has to be installed separately, but somehow, and preferably seamlessly, picked up by the make file, e.g. via some environment variable. Perhaps the SDK already defines an environment variable that can be assumed to exist after installation and thus used in the "bc.mak" make file to pick up the SDK location.Edit: It seems I overlooked the Windows SDK library files, located under "lib/win32c/release/psdk" in the Free C++ Compiler setup. So, the setup on its own may be sufficient to build OWLNext.
Related
Feature Requests:
#100Last edit: Vidar Hasfjord 2016-09-06
I have now added the path to the Windows SDK libraries to my reworked "bc.mak" make file, and it now builds just fine with the Free C++ Compiler setup.
See [feature-requests:#100] for the updated patch. Here is the output from a
maketest, run from a Command Prompt:C:\OWLNext\trunk\source\owlcore>make -f bc.mak OWLVER=7.0.0 COMPVER=720 DEBUG=1 MT=1 MAKE Version 5.41 Copyright (c) 1987, 2014 Embarcadero Technologies, Inc. SubWCRev: 'C:\OWLNext\trunk' Last committed at revision 3485 Mixed revision range 3420:3485 Local modifications found Unversioned items found Version header is up to date. LIBTARGET = ..\..\lib\owl-7.0.0-c720-x86-dt.lib BCCVER = 720 OWL_VERSION = 7.0.0 Embarcadero C++ 7.20 for Win32 Copyright (c) 2012-2016 Embarcadero Technologies, Inc. animctrl.cpp: appdict.cpp: applicat.cpp: [...] initdll.cpp: winmain.cpp: main.cpp: "C:\PROGRA~2\EMBARC~1\BCC101\bin\..\bin\tlib" /P2048 "..\..\lib\owl-7.0.0-c720-x86-dt.lib" @MAKE0001.@@@ TLIB 6.4 Copyright (c) 1987-2014 Embarcadero Technologies, Inc. +"..\..\obj\owl-c720-x86-dt\animctrl.obj" [...]Related
Feature Requests:
#100Hi Sebastian and Vidar,
thanks for your help.
What I did so far:
a) Created 'rsvars.bat' to add bcc101\bin to %PATH%
b) Applied patch "Support for the Embarcadero Free C++ Compiler.patch"
This worked for bc.bat, but not for "source/owlcore/VS/OWLNext.vcxproj" since there is no source/VS path in my 6.35 installation.
I didn't patch and build OWLMaker.
When running OWLMaker now, I get errors like this:
"Error bc.mak 1757: Too many rules for target 'Init'"
for 6 targets before the build stops.
Hi Erwin,
Yes. All you need with the new "bc.mak" provided by my patch is to have "BCC101\bin" in your path as you issue the
makecommand on a Command Prompt, unless you specify the full path tomakeof course (which is what OWLMaker does, by the way).The VS project is set up to use the Microsoft C++ compiler. To make it use the Embarcadero Free C++ Compiler, you would have to do major surgery, and you would gain little.
However, I guess you are just experimenting with OWLMaker, trying to force it to use the Free C++ Compiler. This will not work. Instead, apply my OWLMaker patch. You will then get the Free C++ Compiler in the list of toolset options, but currently only for OWLNext 7 (trunk).
To enable the Free C++ Compiler toolset in OWLMaker for OWLNext 6.35/6.43, the OWLMaker patch will have to be updated. See "OWLMaker/Toolset.h", class TToolsetBCC32C101, member function SupportsOWLNextVersion. This function needs to be updated to make it work with 6.35 (and 6.43).
To add official support for the Free C++ Compiler in OWLNext, someone have to be willing to create similar make files for OCFNext and the other extension libraries as well. Note that, to backport support to 6.35/6.43, the new make files will need a new name, e.g. "fc.mak", since these versions already have "bc.mak" for the classic BCC32 compiler.
I'm upgrading to C++10.1, and we use OCFNext. So I will have time to review the OCFNext project.
We are interesed to move to Win64 bits in 2017.
Hi Sebastian,
I am also upgrading to Berlin 10.1. I noticed in a reply to Vidar that you were able to build a new OWLNext app with it.
How did you build your app? Following the instructions in the OWL Installation Guide, I created an OWL project and built my app, but when I execute it, I get a console window apperaing along side it. How do I get rid of this console window?
By the way, I was unable to follow the instructions exactly because it is not possible to uncheck the Console checkbox in 10.1.
Marvin
Hi Sebastian, note that we already support C++Builder/RAD Studio 10.1 Berlin for OWLNext 6.35, 6.43 and 7, including OCFNext and the other extension libraries. For this product, there is support for the new Clang-based compilers, including 32-bit (BCC32C) and 64-bit (BCC64) support in OWLNext 6.43 and 7. In version 6.35, there is only support for the classic 32-bit compiler (BCC32).
Although OCFNext compiles in all these versions and for all these compilers, I have not done any further testing. I only do build tests for OCFNext, and regressions in run-time behaviour may have gone undetected. So I welcome review of OCFNext.
As for the extension libraries, OWLExt and CoolPrj, I use them for OWLMaker, but that is so far my testing goes.
If you want to add make files for the Embarcadero Free C++ Compiler in OCFNext and the extension libraries, I will review the changes and help with adding support in OWLMaker. If there is demand, I can also backport the changes to 6.35 and 6.43 for inclusion in a maintenance release.
Last edit: Vidar Hasfjord 2016-09-08
Hi Vidar,
after recalling forgotten knowledge on the make syntax I füond the reason for the make errors I got: The patch didn't replace the contents of bc.mak but added the the patch contents. (Maybe I missed something on my first explicit patch use, I executed "patch -p0 patchfile".)
After removing the old contents, the compile started, however with new errors:
e:\OWL635\INCLUDE\owl/control.h:98:3: error: no matching function found in local scope
DECLARE_STREAMABLE_OWL(TControl, 2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1525:5: note: expanded from macro
'DECLARE_STREAMABLE_OWL'
DECLARE_STREAMABLES( cls, ver )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1483:5: note: expanded from macro
'DECLARE_STREAMABLES'
DECLARE_STREAMERS(cls, ver ); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1289:22: note: expanded from macro
'DECLARE_STREAMERS'
friend void ::owl:: READVIRTUALBASE( cls );\ ^~~~~~~~~~~~~~~~~~~~~~
e:\OWL635\INCLUDE\owl/objstrm.h:1252:31: note: expanded from macro
'READVIRTUALBASE'
. #define READVIRTUALBASE(cls) ReadVirtualBase( cls *, ::owl::ipstream& )
Any idea what is wrong?
I'm not sure if related. I've installed C++10.1 on my notebook and when trying to build using OWLMaker I've noticed that the installation doesn't install by default Boost. At first time i've copied the version 1.39 from C++Builder XE but it didnt worked. I've used the GetIt Plugin manager and after that I was able to build OWLNext.
Hi Erwin,
Sorry, I should have stated that the patch is applicable to the trunk (version 7), and is probably easiest to apply using the TortoiseSVN Apply Patch command. To backport the patch to 6.35, more work needs to be done. In particular, the makefile will need a different name, e.g "fc.mak", as I mentioned in one of my earlier replies.
Also, the 6.35 code has not been ported to compile with the Clang-based compilers. You may need to make further changes to the code. You can search through the log for 6.43 to see what changes have been made in this regard, and you can make diffs between the versions to inspect the effective differences (the TortoiseSVN tools such as the Repository Browser is handy for stuff like this).
PS. Why do you need support for BCC32C in 6.35? Although I see many are sticking with 6.35, this version is just meant as a stepping stone to 6.43. If there are issues stopping you from moving to 6.43, I suggest putting the effort into removing these instead.
Last edit: Vidar Hasfjord 2016-09-12
Hi Sebastian,
I've noticed this as well with the trials I've installed. I have now added a note about this in our installation guide and FAQ.
Hi Vidar, thanks for the hints.
... with 6.35, this version is just meant as a stepping stone to 6.42.This is what I planned to do now.
Actually I'm using 6.21. My idea was to switch to an up-to-date compiler in order to bring my application code to an acceptable state. Since I use BCC5.5 via a makefile, this step was quite easy to achive with BCC101. The plan was also to stay with 6.35 for this step for testing changes so far.
Then, migration to 6.4x should be much easier, I guessed.
But as the situation turned out to be, it seems that I have to change my strategy.
I could either switch to VS (which I have only little experience with) and 6.35, then migrate to 6.4x.
Or, I try to do both steps (BCC55 --> BCC101 and 6.21 --> 6.4x) together and switch to VS somewhen in future.
What do you think might be easier?
Erwin:
We switched from OWL 5 to OWLNext 6.20 8 years ago using the C++Builder 2007.
The modifications in our code were minimal and by some time we used dual compile to keep working in BC5 and C++Builder2007. Most of those modifications were for OWL 2.x code and some signatures in members functions like GetClassName();
By using:
we managed to mantain our code compatible for both compilers.
After that we moved to OWLNext 6.30 first with C++Builder 2009 and later with C++Builder XE.
I've just installed C++Builder 10.1 this saturday, builded OWLNext 6.45 and moved a first project to the new version of compiler/library. We even managed to build our first 64bit OWLNext app. The new C++/Clang compiler it's really beatifull and very valuable.
The typical modifications to move to 6.35/6.4x is to add:
in our headers and at the very first of our source code:
I know that some issues will appear, but so far the new C++Builder 10.1 it looks really good.
Last edit: Sebastian Ledesma 2016-09-12
Hi Erwin,
First, I think you need to decide on your modern development tools. Depending on your choice, then there are two ways to proceed.
If you are looking for the free route, note that Visual Studio Community Edition is free for open-source and small business. This is the way I went with my software. I recommend it as a good fit for anyone used to the Borland C++ IDE (integrated editor, debugger and resource editor). Try it out. It is freely available to download.
You can also freely check out the Embarcadero option by downloading a time-limited trial.
Hope that helps.
Last edit: Vidar Hasfjord 2016-09-12
Hi Sebastian,
Good to hear!
Hi Vidar,
How did you build your app? I just installed the Berlin 10.1 compiler and moved my code over. Following the instructions in the OWL Installation Guide, I created an OWL project and built my app, but when I execute it, I get a console window apperaing along side it. How do I get rid of this console window?
Marvin
Hi Marvin,
I'm not a C++Builder user. However, in Visual Studio, the setting "Configuration Properties | Linker | System | SubSystem" controls whether or not to build a console application. For a non-console OWLNext GUI application this setting is set to "Windows (/SUBSYSTEM:WINDOWS)".
Last edit: Vidar Hasfjord 2016-12-29
Thanks Vidar. Unfortunately, I had thought that it was you who built your "first 64-bit OWLNext app" with Berlin 10.1. But it was Sebastian.
The Berlin 10.1 compiler does not has the same settings as Visual Studio. I will have to re-send my post to Sebastian.
Thanks for your help anyway,
Marvin
Hi Marvin,
what's about opening an existing project like aclock.cbproj and then modify it?
Erwin
Hi Erwin,
Actually, I discovered an easier, but similar, method. I created a new project as indicated in the OWL Installation instructions. I then openned that .cbproj file and made 2 simple changes:
and
Marvin
Hi Vidar, Sebastian,
thanks again for your advise.
Looks like I should come back to VS (I already did first steps 2 year ago with several issues left however).
Hi Vidar,
I switched back to BCC5.5 now to complete the migration to 6.35.
One unsolved issue is my use of TSystem::IsWin95() which I need to continue for some time. In 6.35 it is only available in OWL5 compatibility mode. I don't know what side effects will appear when I use it, so I better would create some workaround for this special case, right?
Or what would be your suggetion?
Hi Erwin, TSystem::IsWin95 is just a wrapper for Windows API function GetVersionEx which is deprecated and may no longer work as you expect:
Henceforth, OWLNext will no longer use this function, and there will be some changes in TSystem. See [bugs:#323], "TSystem returns incorrect information".
Related
Bugs:
#323