Bör jag fortsätta eller är det dött lopp?

Det var nog många saker som fick honom att gå ut med att säga så. Han har ju skrivit mycket negativt om C++ då och då, genom åren, och det är ibland väldigt rolig läsning, tycker jag

C ska vara invecklat och jag säger inte att det är svårt, men från början, när C utvecklades, var projekten som var menade att ha med C i koden till dessa projekt väldigt low-level, till exempel kerneln till Unix.

C++ är ännu mer invecklat och enligt mig är C++ rätt onödigt om man snabbt vill komma igång och skriva en kernel (men smaken är som baken) eftersom det är en del tillägg man ibland behöver göra för att då få sin kod att fungera.

Det var just det som gav mig spader när jag tittade på MFC efter att ha jobbat med OWL. Det fanns få eller inga abstraktioner i MFC. Eller åtminstone var de extremt "leaky".

Grundproblemet var väl att de virtuella tabellerna blev ohemult stora och käkade minne. I första OWL-versionen löste man det med att utvidga språket med ett hemkokt tillägg, dvs ett ful-hack, sedan ersattes ersattes fulhacket med macron.

Ja, dessutom blev det en stor vtable för varje anrop så hela stacken kunde bestå av en mängd sådana, det tog också onödiga CPU-cykler att traversera dessa. Dessa kunde också referera till varandra, och i sin tur ge upphov till cirkulära referenser (dvs oändliga loopar) och ev oändlig rekursion.

Inte så enkelt för utvecklaren att se det heller bara så där rakt av.
Ful-hacket var ett avsteg från att denna variant av C++ kunde sägas följa standarden till 100 %.
Fulhacket och sedermera macro-expansionen låg inbyggt i källkoden
till hela OWL-paketet.

Men faktiskt att MFC blev tvungna att konstruera ett liknande "fulhack" för att få en acceptabel prestanda.

MFC blev en slags halvtaskig hybrid mellan C++ och C.
Denna hybrid berodde tydligen på att C++ kod skulle vara bakåtkompatibel med C och att det skulle gå att länka ihop kod skriven i C ihop med C++.

En del datatekniska artiklar tar upp problemet med vtables på ett ingående sätt, att detta blir en börda för C++.
Och kunde kanske kunna lösas med en funktionspekare som pekar direkt på en medlemsfunktion i ett visst objekt, men C++ syntax tillät inte detta då.

Här finns visst förklarat om pekare till medlemsfunktioner, men det verkar som att
det är sällsynt att de används. De kan i teorien förkorta vtables absebärt och ge en snabbare exekvering:

https://isocpp.org/wiki/faq/pointers-to-members

Flera av frågeställningarna där är överkurs way out kan man säga ?
Men definitivt mycket intressanta.
Instressant är att vissa definitioner kräver att objektet deklarares som "static".

Ja, nej det var visst DOS fast den debuggern hette TD.EXE - 32-bits varianten hette TD32.EXE och var bägge skrivna i Turbo Vision. Ett kraftigt förenklat grafiskt GUI, och det var enbart teckengrafik i det.
Ungefär som gamla 16-bitars EDIT.EXE, som sedan blev förlagan till Notepad.exe


En kernel kan mycket väl skrivas i C, det är inget mystiskt med en kernel, det är ett program som alla andra. Men den har fixerade förutsättningar när kerneln startas. Maskinresurserna är fixa från start.

Kerneln har egna hemkokta varianter av att skapa dynamiskt allokerbart minne, av det som finns.

Teoretiskt finns det inget hinder att skriva en kernel där man kan lägga till RAM under körning.

En intressant funktion är relokering av redan allokerat minne att det kan flyttas även
under körning.
Detta för att åstadkomma nya minnesareor som då blir sammanhängande.

Och jag vet inte vilka versioner av Windows som man kan öka mängden virtuellt minne under körning.
Har för mig att flera av serverversionerna klarar av det. Vilket kan vara värdefullt om programvaran måste köras på serverhårdvaran, och att klienterna har varsina konsol/GUI/Fönster på sina skärmar.

Denna lösning var det många aktiemäklare använde sig av. I början med Novell Netware,
som ersattes av Windows Server (NT).

Dessa servrar kunde inte ha så många nätverksanslutningar öppna åt gången då, men att
aktieprogramvaran kunde köras på servern och då garantera att dess databaser
uppdaterades korrekt.

VMs kan upptäda lite kosntigt, tex att man kan böva en lös dedikerad mus, en enkel lasermus.
Alla VMs med Guest-OSes är det inte säkert att de kan hantera pekplattor längtr

Här finns en ny Win 16 emulator liknande Wine som verkar vara intressant eftersom den verkar vara helt transparent när det tex gäller långa filnamn:

https://www.codeproject.com/Articles...ively-on-64-bi

Installera Borland C++ 3.1 i den VM så kan du leka med att bygga gamla Win 16 program ?
Eller Borland C++ 4.5 eller 5.02.

Mycket retrokänsla i det.

Jag tror att en av de franska Ariane-raketerna hade mjukvara utvecklat med Borland.
Som gjorde att raketen störtade pga övergång till annan COU

Idag heter Borland inte Borland längre utan Embarcado och är ett spanskt kodutvecklarbolag.

De verkar syssla mycket med konsulttjänster nuförtiden.


Tja, jag vet inte, i början av tiden med Unix/Linux så var mycket av arbetet ideellt.
Många av dåtidens utvecklare var rena akademiker, och hade sin lön garanterad ändå, genom sitt jobb.
Men dagens utvecklare har helt andra perspektiv och ekonomiska horisonter, de är tvungna att dra in mycket pengar med tanke på att de flesta
köper sitt boende med (stora) lån idag.

Det bådar inte gott inför framtiden att många appar/program kan falla för åldersstrecket, att det finns inga kvar som behärskar den gamla tekniken.
Att lägga till och uppgradera funktioner, mm...
Men det kan också finnas rättighetsproblem som inte är så enkelt att överbrygga
i dagens utvecklarmiljöer.

Vi vet inte ens hur länge som Microsoft kommer att behålla stödet för Win 32.
Det har diskuterats lite fram och tillbaka de senaste åren.

De gamla rävarna behövde inte ha samma sug efter penningarna, som dagens unga rävar måste ha.

OBS: Om du/ni sysslar med virtuella maskiner så kom ihåg att en VM är inte bättre eller sämre än alla andra program vad gäller riskabla dataförluster.
Så laborerar du/ni mycket med VMs så får du räkna med att krascher kan hända, och att
du förlorar dina data. Så regelbunden backup blir absolut nödvändigt.

C, Assembly, och att skriva en kernel är faktiskt väldigt bra att göra även när man börjar programmera men kanske inte helt i början.

Teoretiskt sett går det att skriva en kernel i vilket språk som helst, men att vissa delar i språken kanske då behöver modifieras. I C# och Rust ska det gå utan detta. Problem med andra språk kan komma om fixerade minnesadresser, virtuella minnesadresser och pekare ska användas. Man kan nog då koppa koden till Assembly eller C-kod (kanske C wrappers) där minnesadresserna definieras.





Absolut, och den sköter det virtuella minnet också.



Nej, men åtminstone i x86-baserade system så finns det praktiska industriella hinder. Där är det BIOS som sköter the memory controller i början innan kerneln startas. Den kan använda cacheminnen med speciella sätt att lägga data på stacken innan RAM startas. Efter att den är färdig stänger BIOS ner åtkomsten till the memory controller för kerneln.

Det finns till och med, i nyare datorer, hårdvarulås som låses upp när datorn startas som, och då kan BIOS ha åtkomst till the memory controller igen, men under tiden kerneln körs så är datorn som ett frågetecken när ny RAM läggs till.
Nu nämner jag x86-baserade system och jag vet inte hur det fungerar med andra datorsystem.

Inget jag har hört talas om men det är mycket möjligt eftersom Philippe Kahn köpte en TBM700 (turboprop-kärra) pga viss insyn i Aerospatiales inblandning i dess konstruktion. Det kan ju ha varit så att han fick den inblicken om han hade ett finger med i Ariane-projektet.

Du tänker nog på Embarcadero, ett amerikanskt bolag som köpte delar av Borland (bl a Delphi) medan Micro Focus köpte resten. Av någon anledning finns det fortfarande folk som sitter kvar Delphi.

Det har ju varit ett antal fall när någon FOSS-utvecklare har lyckats hamna i ett förhållande eller t o m skaffat barn, vilket har dödat intresset för att jobba gratis som hobby.

Hur gick det för TS, gick du klart utbildningen och fick du jobb?