OWL future for Pascal lazarus / 64-FPC development ---------------------------------------------------------------------- rhohpe · 2023-12-30 05:52 Hello to all people here, Thank you for of your hard work to make all these possible. Free Pascal a compiler for the past the present and the future. I open this thread to ask the development team if there is a plan to compile - maintain - freshen the OWL to the Freepascal world! I use PLs for the past 30 years i used Delphi and Lazarus for years making usable software for personal and public domain use. In the last 20 days i did an experiment. I downloaded in my retro PC running win2000 TPW 1.5 and tried to make a text editor app. Then i found there is a way to build win32 apps using Virtual Pascal now a free software so i installed VP in my win10 pc and continue the experiiment from here. Then i found a modern code editor PascalXE that allowed me to be more productive. I am not a good programmer but at least with my long years into this i understand the plus and the minuses of a programming environment. And yes having a little experience in Purebasic and seen code with Powerbasic i believe there is some place for this OWL implementation that had programmers for almost eight years 1991-1999 some of them then went to MFC and QT because of the paradigm they used to use and some others went to RAD being productive for the next years. So i am asking the Free Pascal Community if it's a goo idea another small tool more to be born not to replace or a competitor to Lazarus. But a standalone API wrapper a small IDE to produce win32 utilities. People at C++ department (in my opinion only C, C++ and Pascal are real programming languages) made it happen! The OWLNext for C++ why not the OWLFree for Pascal! I also beleve that the FreePascal Lazarus team can do this in a matter of months. Lazarus is so much more complex to implement. (My editor an 80x25 utility is totally incomplete and missing tabs, file list viewer at the right and more, plan for Richedit instead of miltiline Edit, line numbers, line,col position update and more...i find somehow how to make them! But is fun to have the same codebase and logic with C and C++). ACCELERATORS_1 ACCELERATORS (just to know how to use features!) {  VK_F2, 521, VIRTKEY Open file  VK_F3, 721, VIRTKEY Find first  VK_F4, 821, VIRTKEY Find Next  VK_UP, 823, VIRTKEY, CONTROL Page Up  VK_DOWN, 824, VIRTKEY, CONTROL Page Down  "^A", 822, ASCII Select All  "^O", 603, ASCII Open file  "^N", 602, ASCII New file  "^B", 619, ASCII Bold  "^S", 604, ASCII Save  "F", 618, VIRTKEY, ALT Fit text  "R", 617, VIRTKEY, ALT Regular text  "[", 615, ASCII, ALT Smaller font  "]", 616, ASCII, ALT Bigger font  "^F", 621, ASCII Search init } Yes i agree i could that in Lazarus in two hours! ---------------------------------------------------------------------- marcov · 2023-12-30 11:57 The FPC win32 support doesn't even support win9x anymore, so on 32-bit it is not even a possible to target very memory constrained (4-8MB) win9x machines with OWL, which defeats the purpose. I think OWL might be more important for 16-bit win 3.11 support, but while FPC has win 16-bit support in trunk, I don't know much about it. Afaik also in recent years the designer was more loosely coupled within lazarus, so it might be possible to have a OWL designer in lazarus, if the people wanting OWL want it badly enough. ---------------------------------------------------------------------- rhohpe · 2023-12-30 14:27 Quote from: marcov on December 30, 2023, 12:57:23 pmThe FPC win32 support doesn't even support win9x anymore, so on 32-bit it is not even a possible to target very memory constrained (4-8MB) win9x machines with OWL, which defeats the purpose. I think OWL might be more important for 16-bit win 3.11 support, but while FPC has win 16-bit support in trunk, I don't know much about it. Afaik also in recent years the designer was more loosely coupled within lazarus, so it might be possible to have a OWL designer in lazarus, if the people wanting OWL want it badly enough. Thank you for replying to the post. I have the sense that Borland should not left the OWL for VCL but it was better to keep both. The first as a low level tool for competing with MFC keeping the native GUI development and the VCL mainly for bussiness/database development (vs Powerbuilder) or Rapid in General (vs Visual Basic) and for the Web (at the time). The VCL / LCL is very big weapon but abstracts  the connection of the user with the OS. So leads to programmers that provide solutions but abstracted from OS nature. Very few the best of them are not mixing the visual components with the program logic. But tools must guide the most not only the best.  OWL is an OOP library using an angry Pascal inside the heart  of the OS. Millions of users use the win32 API the web is full of samples to do anything you want in C or C++ but easily converted to Pascal because the nature of these two languages are the same. So the common codebase of users would be huge over the years.  The Pascal paradigm had to be on par with the C++ paradigm and not the VB , .NET, C sharp , Java. But to do that you have to loose a little on productivity in my opinion worth to. ---------------------------------------------------------------------- Thaddy · 2023-12-30 14:39 OWL was tied to C++ older versions. Not Pascal, although      feeble attempts have been done.. It was also badly designed and never used very much. So it is a bad idea to would have want support for it in FreePascal. Actually, Borland engineers at the time called it a monster in hindsight. (I did some work for Borland at the time, I am really informed) Guess why OWL or any parts of it did not even make it into the then current C++ standards? The Pascal equivalent: TurboVision, was a much better attempt but nothing to do with OWL.. Which died a quick death. (1999) I will have a quick look at OWLnext, though. But I can tell you rightaway it probably makes no sense if it is based on the flawed same mechanisms. Back in the days there were long discussions about OWL being " too deep" versus MFC being "too shallow" OWL was a hog to work with. [edit] The wikipedia entry is way too kind. ---------------------------------------------------------------------- Thaddy · 2023-12-30 15:02 The OWLnext website is brutally honest too, just like I already summed up. (Positive side from my p.o.v.: I have a license...) ---------------------------------------------------------------------- marcov · 2023-12-30 20:12 Quote from: rhohpe on December 30, 2023, 03:27:28 pmI have the sense that Borland should not left the OWL for VCL but it was better to keep both. The first as a low level tool for competing with MFC keeping the native GUI development and the VCL mainly for bussiness/database development (vs Powerbuilder) and  for the Web. The VCL / LCL is very big weapon but abstracts  the connection of the user with the OS. So leads to programmers that provide solutions but abstracted from OS nature. Very few the best of them are not mixing the visual components with the program logic. But tools must guide the most not only the best.  OWL always felt as a failed first attempt to me. Attempt to do a bit of OO, but kept it too close to the C Api to really be heaps better than purely procedural windows code. The VCL is also a fairly light abstraction, the whole object layout mostly fits 1:1 to GDI objects, and easy to enhance with win32 code. The only advantage of OWL was on 16-bit win3.x (win32s), where it originated and had was designed with the extremely constrained memory of the time. But what does that mean in a 64-bit world where 32GB Dram costs Eur 60 ? ---------------------------------------------------------------------- domasz · 2023-12-30 20:21 Quote from: rhohpe on December 30, 2023, 03:27:28 pmMillions of users use the win32 API the web is full of samples to do anything you want in C or C++ but easily converted to Pascal because the nature of these two languages are the same. C/C++ are primitive wrappers around assembly from the 70s and Pascal is a modern, well thought language which can compete with Python, PHP, Java or anything really. win32 API is also terrible. If you don't have documentation detailed enough you won't do shit with it. ---------------------------------------------------------------------- rhohpe · 2023-12-31 07:39 All i meant in my post  about Win32 API, is that maybe back then  existed a little space for a thin API wrapper to coexist with the invention of VCL/LCL not because there is any productivity into that but because similar frameworks like MFC survived better during the years. Dont forget as we getting older (i mean myself) we tend to overestimate older things we used in the past!  I remember i bought a book in my local language (Greek) for Turbo Vision and tried to understand OOP after all procedural logic embedded in my mind! I never wrote a line without seeing it first on the book or the demo programs! I also have memories when i first installed TPW 1.5 at about 1994 as a student. Windows programming! But when i opened the samples i told myself it was for sure only for people in USA! It was impossible to do anything without the help even i tried hard to read the hlp files that was very good! At the later years of my studies i used Delphi at the university and made crazy things for the time and my skills! I even teached Delphi at a college for some months i remember i used a book to help myself into that. The book was  "Delphi in-depth" ISBN 0078822114. And never looked back.... Except now after 25 years. ---------------------------------------------------------------------- marcov · 2023-12-31 18:39 Quote from: rhohpe on December 31, 2023, 08:39:55 amAll i meant in my post  about Win32 API, is that maybe back then  existed a little space for a thin API wrapper to coexist with the invention of VCL/LCL not because there is any productivity into that but because similar frameworks like MFC survived better during the years. The problem is that it never had the numbers that MFC had in the first place. C++ people had no choice till years and years later when QT got more mainstream popularity as a mature and portable framework. QuoteDont forget as we getting older (i mean myself) we tend to overestimate older things we used in the past!  I remember i bought a book in my local language (Greek) for Turbo Vidion and tried to understand OOP after all procedural logic embedded in my mind! I never wrote a line without seeing it first on the book or the demo programs! I'm probably slightly older (started with TP6 in 1990), but yeah, I also had a Turbo Vision book in Dutch. But for programming I skipped the 16-bit Windows programming, sticking with Dos till about 1998-2000, so TPW ---------------------------------------------------------------------- rhohpe · 2024-01-03 16:03 I wish all of you a Happy New Year! A little history now! I found this article : https://blogs.embarcadero.com/the-origins-of-delphi-rd-recounted-by- danny-thorpe-original-delphi-1-team-member/ Somewhere the author and "quality assurance" member of the Pascal team at Borland back then Eli M. writes: The OWL application framework of Turbo Pascal for Windows (developed for Borland by a contractor experienced in Windows development) provided many examples of pain points we did not want to repeat in Delphi. So in that regard, development of Turbo Pascal for Windows starting ca 1991 also contributed to the architectural and thematic goals and philosophies of Delphi and VCL. One of the hard lessons learned from the Turbo Pascal 6 Turbo Vision framework and again from OWL was that object frameworks tend to create a high barrier to entry. Object inheritance and virtual method overrides require the developer to understand a lot about what they are inheriting from, what it does for them, and what it requires of them. This realization led to the event-driven programming model of Delphi, which all but eliminated prior knowledge requirements on developers. Events are largely “contract-free”, requiring no knowledge of inheritance or virtual overrides. This makes it much easier to get started and be productive with Delphi compared to previous products. So TPW was a product of other company and not Borland (i think a company somewhere in Europe - Denmark?).  I think this answers the question why there are so many Pascal developers in Germany and France and Central and East Europe in general. ---------------------------------------------------------------------- domasz · 2024-01-03 16:20 Quote from: rhohpe on January 03, 2024, 05:03:34 pmSo TPW was a product of other company and not Borland (i think a company somewhere in Europe - Denmark?).  I think this answers the question why there are so many Pascal developers in Germany and France and Central and East Europe in general. Central and Eastern Europe was occupied by USSR until 1990. Which means people were extremely poor and most computers were cheap ones (Commodore 64, Atari 8 bit, ZX Spectrum) or local clones of those. On those machines you either used Assembly or Basic. In later years migrating from Basic to Pascal was easier than migrating from Basic to C. Turbo Pascal was taught in many high schools and later Borland released Standard versions of Delphi for free.