|
On one of my recent threads (EDIT, it was a thread @ PhysicsForums), someone commented that OpenOffice has not been updated in 8 years, and thus I should junk it for LibreOffice. I've installed LibreOffice, but for whatever reason, I just didn't like it. Perhaps I just don't like the way the font-typeface dropdownlist is larger, making scrolling through that more of a chore. Perhaps I just like the UI of that era.
OpenOffice seems to do everything that I want, except for making a split window for Text, which would be nice. There are extensions that seem to exist for everything extra I want. I think that sometimes software gets capable enough so that there really doesn't need to be any more major enhancements, security issues excepted of course. I have the Chessmaster app from 2006 or so, and it works fine (beats the h3ll out of me even when I give it just a few seconds per move, LOL), and I think that the developers just realized that they put in as much stuff as they could without doing a radical new design. I think Windows 7 was in a similar situation; Windows 8 was a turd, and Windows 10 is only good because it went back to the look & feel of Windows 7.
modified 25-Aug-18 19:35pm.
|
|
|
|
|
swampwiz wrote: but for whatever reason, I just didn't like it
It is probably the big jump over 7 years of changes... I moved to LibreOffice close to Oracle takeover and the changes came bit-by-bit...
As for the OpenOffice package - Oracle gave it to Apache in 2011 and since then it developed there, and definitely not dead (maybe a bit slower development cycle), so no real reason to switch...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Has anyone managed to get the .NET Core SDK installed on Raspbian? I got the runtime installed but was disheartened to not find an SDK that was compatible.
By the way, thanks @jovitadsa for the Pi 3 B+. 
|
|
|
|
|
|
Yeah, I tried that and other pages with official, and unofficial instructions. Nothing worked for a while. Finally, manually got the url to the download, wget'd the file, and manually set it up. Got it working now. Took forever to build a hello-world app. I guess the processor is too slow for build/compilation.
|
|
|
|
|
Finally got VS Code installed too. It's really slow. This is not how it's meant to be used. I just wanted to see how it'd look like on the Pi.
|
|
|
|
|
You are most welcome. Glad you're enjoying it Nish!
|
|
|
|
|
What is the theory behind making the default calling convention cdecl?
It leads to larger code and it's fundamentally incompatible with OS APIs.
What were they thinking?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Just googled your subject, did not read it: Calling Conventions Demystified[^]
And btw: I don't care about this additional Bytes caused by cdecl vs. others. In case I use a math lib (dll) from where I use most probably only 2% of it I "waste" much more Bytes
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Thank you for your opinion.
It's good to hear from someone more knowledgeable on this subject than I.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Quote: It's good to hear from someone more knowledgeable on this subject than I.
Please use sarcasm-- 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Why? Might be bias or random.
But one could say that if it was thought about then perhaps because it was much more likely, when it was originally specified, that one would be calling a library that used exactly that calling convention. Probably almost always.
But since it wasn't 100% they needed to account for the other cases.
|
|
|
|
|
Probably, backward compatibility.
There was a huge reservoir of C libraries back than, and since C++ wasn't a "new language" per se but a superset of C it would have made sense to design it to work with existing code.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's a very interesting point, because I just assumed that C's default convention was stdapi. The reason I assumed that is that when you want to export a function from a C++ DLL, you usually enclose the declaration in extern "C".
But I never considered that C's default convention was cdecl.
Well played.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: But I never considered that C's default convention was cdecl.
Hence the name, "cdecl"
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: Hence the name, "cdecl"
And that's why I come to this board! I always learn something interesting.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
extern "C" indicates that C++ name mangling should not be used - just the plain function name, not decorated with the types of the function arguments for overload resolution.
|
|
|
|
|
Your partly correct, indeed it indicates that C++ name mangling should not be used. But this does not mean plain function names. It's mangling the way c get's mangled. For example a function returning a 32 bit int would be something like function@4 and if u take stdcall c function by a microsoft vc compiler u often get even more mangling on the function name.
|
|
|
|
|
It is the opposite, *they* did the OS the wrong way.
|
|
|
|
|
The reasons are mostly historical. The cdecl convention allows for variable-length parameter lists (as required by the printf and scanf families, etc.). For all I know, it may also have been more efficient on the PDP-8 and -11, which were first used to run C.
In order to maintain binary compatibility with C libraries, many C++ compilers also adopted the cdecl convention as default.
Windows 1.0 was originally compiled to use the cdecl convention. Microsoft discovered that the executables would be smaller with the pascal convention (and, IIRC correctly, fit on one less diskette), so they switched.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: so they switched.
bad decision
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
When Windows 1.0 was released, most PCs used 8088s. A high-performance machine used an 80286, and the 80386 was just coming on the market. We looked for every possible way to eke out some extra performance. Microsoft's decision made sense at the time from both the technical and the production standpoints - saving three bytes and one instruction for each function call, and shipping Windows on one less diskette.
Windows was from the beginning designed to be programmed in C. Unless you were writing code in Assembly language (mostly device drivers), the difference between the calling conventions was handled by the compiler and so was transparent to the programmer. At the C level, it makes no more difference than big-endian vs. little-endian.
(Now, let the Religious Wars resume... )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Very good information!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Quote: Windows was from the beginning designed to be programmed in C.
That is true if you never opened a window before it became 32 bits.
The native calling convention of the original 16 bits Windows was the Pascal way of doing it.
|
|
|
|
|
- The Windows SDK was always published first in C. If any ports to other languages occurred (e.g. Borland's Borland Pascal), they were delayed by some months.
- As my OP said, the calling convention is handled by the C compiler, so unless you are programming in Assembly language, it is irrelevant.
I stand by my statement.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
