MAL Wieder "C" Frust

[Siro]

Hallo zusammen:

Ich wollte gestern mal eben eine Software für mein RIGOL Oszilloskop installieren,
Dies schlug aber fehl, weil irgend etwas mit Microsofts Redistributable nicht in Ordung ist.

Keine Ahnung was das sein soll,
in meiner Systemsteuerung konnte ich finden, das es "ETLICHE" von diesen Dingern gibt.

Bei weiteren Recherchen scheint es so zu sein, das man die NUR braucht wenn jemand Software in Visual C++ geschrieben hat ???

Ich bin echt, mal wieder genervt von dem "C" Mist.....
Kann man keine Programme mehr in "vernünftigen Programmiersprachen" schreiben, die auch funktional sind....

Ihr wisst ja, dass ich ein "C" Gegner bin und irgendwie werde ich immer wieder bestätigt.

Wenn ich in Pascal, Delphi oder Lazarus ein Programm schreiben, dann habe ich genau EINE .EXE Datei, die funktional ist.

Zumal scheint es ja ZIG Versionen von diesem Redistributable zu geben, wo jedes Programm anscheinend sein eigenes benötigt.
Welche Programme die benötigen weis ich nicht, das werde ich merken wenn ich alle rausschmeisse.

So, der Frust abgelassen

kann man die Dinger einfach so rausschmeissen und im Zweifelsfalle wieder nachinstallieren ?
Das sind ja wohl irgendwelche Bibliotheken, und warum kann man die nicht gleich mit ranlinken, dann bräuchte man die doch garnicht.

Siro

[Ceos]

Ihr wisst ja, dass ich ein "C" Gegner bin und irgendwie werde ich immer wieder bestätigt.

hey hey hey hey bitte! Schmeiß hier C nicht mit C# und .Net zusammen, das ist echt mies!

Delphi oder besser gesagt Pascal (ist ja nur ein Dialekt von Pascal) sind zwar leichter als Anfänger aber in Performance kommt man nicht an ordentliches C/++ ran!

Das hier für ein Oszi massiver Gebrauch von .Net gemacht wird ist ein M$ Problem. Die von Rigol sind wohl primär C Programmierer (für die Firmware der Oszis) und müssen dnan auchnoch eine GUI dafür schreiben (selten schafft sich dafür eine Firma einen dedizierten Anwendungsentwickler an, wenn sie schon Programmierer haben)

Und wenn du schonmal Windows API mit reinem C gemacht hast wärst du nicht hier sondern hättest dich wohl schon erschossen :P (Sinnbildlich, es ist zu kotzen, das kann cih dir sagen)

Also nimmt man Visual Studio und das ist halt mit .Net zugekippt ... um es noch schlimmer zu machen hat man als trölfzig Stellen die Möglichkeit die gleiche Eigenschaft zu verändern damit etwas so aussieht wie es soll, nur wenn man anfängt an trölfzig stellen rum zu fummeln funktioniert hinterher garnichts mehr ... deswegen sage ich ja dass man eigentlich einen .Net gelernten Entwickler (der die Struktur hinter .Net begreift) für sowas braucht, auch wenn jeder hinz und kunz "mal was programmieren kann" mit .Net ... nur eben nicht richtig.

Aber da Ende vom Lied ist wie bei Java ... man muss die Redistributables eben mit reinpacken ...

schau doch mal in die zip ob da nicht ein isntaller neben der ssetup.exe ist (.msi z.b.) der bringt das notwendige paket meist mit.

Rausschmeißen würde ich sie nicht sonst funktioniert irgendwann irgend ein anderes Programm nicht ... wenn du nicht gerade eine zu kleine Festplatte hast würde ich sie lieber drin lassen

Und wenns erlaubt ist zu fragen, wo ziehst du deine Grenze der Aversion was C/++/# angeht denn? Ich muss gestehen dass mir persönlich C++ schon nciht schmeckt weils eine Symbolüberhäufte Sprache ist ....

"hey du hast da ein ":" vergessen ... ich schmeiß jetzt mal n kryptischen Fehler an irgend einer andern Stelle deswegen"

oder mein top favorit

"hmm ... da müsste eigentlich ein ":" stehen ... tut es aber nicht ... egal compilen wir es trotzdem und verhalten uns am ende einfach affig"

und was .Net angeht, finde ich es herrlich wenn sich ein Ingenieur damit versucht und du am Ende eine Episode von 1000 Wege ins Gras zu beißen mit der Anwendung machen kannst weil der ingenieur linear denkt und alles in einem einzigen Thread schreibt weil Thread-Handling ne Wissenschaft für sich ist und du dann an der GUI zugucken kannst was das Programm im Hintergrund rechnet.

Bestes Beispiel dafür ist eine Profi-Fräse von einem Namenhaften Hersteller dessen Software sogar das Kamerabild während des Fräsen zeigt ... aber die GUI bei jeder Bewegung inklusive Kamerabild einfriert solange die Fräse eine kontinuierliche Bewegung ausführt, weil der Steuerprozess im selben Thread wie die GUI läuft und die Methode zum verfahren auf das Ende der Fahrt wartet


PS: um mich Shedepe an der Stelle ein kein wenig entgegen zu stellen, ich habe beide Welten programmiert, Borland Turbo Pascal (und die können einem auch herzlichen mit Packages und Libs um die Ohren fliegen) und intensives Anwendungsentwicklung mit C++ .Net .... ich mag Pascal echt lieber weil es eindeutiger ist, aber schneller ist halt immernoch OS-Nativ mit .Net

[shedepe]

Ohne jetzt mal auf deinen Rant gegen C einzugehen:
Überlege dir mal warum es eventuell eine schlechte Idee ist fest gegen Bibliotheken zu linken. Eine davon ist: Du kannst ansonsten keine Updates der Bibliothek machen z.B. bei Sicherheitslücken. Das ist vorallem bei so zentralen Sachen wie dem was in der Redistributable drin ist sinnvoll.
Die Unterschiedlichen Versionen kommen daher, dass für jede Major Version ein neues Release gemacht wird (dann wenn die Kompabilität gebrochen wird).

Btw. Du kannst auch in C diese Bibliotheken fest reinlinken. Ich würde es dir nur nicht empfehlen. (Und mach doch bitte noch einen Unterschied zwischen Visual C++ und normalen C/C++)

Und um doch noch auf deinen Rant einzugehen: ich bin entschiedener Delphi Gegner

[Siro]

Hallo Ceos und shedepe
es ist nicht ganz so negativ gemeint, wie es aussehen mag....
aber da wir hier im "Tratsch" Thread sind, kann man mal vom Leder lassen

Ich kann ja zu C# C++ oder.NET z.B. garnichts sagen, da ich nie damit gearbeitet habe...

Aber ich war "mal wieder" genervt, als ich ergoogeln muste,
das die Rigol Software nicht funktioniert, weil sie anscheinend in einer Variante von "C" geschrieben wurde.
Wobei dies anscheinend C++ ist.

Die Abneigung von "C" hat bei mir viele Gründe, wobei ich nun nach zig Jahren programmieren in "C"
für Embedded Anwendungen die meisten Hürden erlebt und überwunden habe.
Habe mit dem "normalen" C eigentlich gar keine Probleme mehr.


Irgendwie hab ich gelesen, das man die Software bei C++ wohl hätte "statisch" linken können, dann bräuchte man wohl
die Laufzeitbibliotheken garnicht, zumindest hab ich das so verstanden. Deshalb finde ich es sehr schade,
dass Rigol eine so "halbherzige" Software dazu liefert.
Hab grad gelesen von shedepe, dass es aber nicht unbedingt sinnvoll ist wegen Updates etc.

@Ceos:
Windows API programmieren:
Jo, is geil, wenn man dann Masochist ist

Ich hab da auch so einige Erfahrung und bin immer wieder mal dran an der API
Hab mal am Audio Interface programmiert (Multimedia Api) und vor kurzen grad wieder RS232 und Timer..
brauchte eine serielle Schnittstelle die mit den FTDI oder SILABs Treiber kommuniziert.

Zurück zum Redistributable:
Ich muss mal gucken welche Version die Rigol Software braucht und Du hast recht,
meistens haben die Installer gleich eine Version der Bibliothek mit installiert.
Da werd ich sicher noch fündig.


@shedepe:
Ich bin auch ein Delpi Gegner geworden, da es einfach ÜBERTEURT war und nun ist Lazarus (Open Source Freeware) mein Nonplusultra...

Siro

[Ceos]

RS232 mit Windows API .... Strg + A, Strg + D, Strg + S .... wegrenn

ich pack mir immer eine POSIX UART Lib dazwischen ... sonst wird man beim setzen der serial struct irre

[Siro]

@Ceos:
Du meinst bestimmt die Struktur DCB, muss man mögen

Viel interesanter fand ich, um zu ermitteln wieviele Bytes sich im Empfangspuffer befinden,
muss man die Funktion "ClearCommError" aufrufen. Da muss man erstmal drauf kommen....
und da es keine UART Interrupts mehr gibt, habe ich diese Funktion nun in einen Timer packen müssen,
weil ich Zeitnah (sofern man das bei Windows überhaupt erwähnen darf) meine Daten haben wollte.

[HaWe]

gegen C ist eigentlich nichts zu sagen: es ist klar definiert, schreibt extrem wenig vor, kann so gut wie jede Hardware adressieren und händeln, hat nur knapp 20 fest definierte Bezeichner, eine extrem einfache Syntax, und die Executables sind rasend schnell.
Nicht umsonst werden ganze Betriebssysteme damit geschrieben (wozu es ja gerade entwickelt wurde).
Alles was du bemängelst, betrifft die libs, die andere Leute geschrieben und zu vertreten haben, und da gebe ich dir völlig Recht: da ist irrsinng viel Schrott unterwegs.

[Siro]

Hast Du nicht unrecht HaWe, jede Sprache hat Vor und Nachteile.
Ich hab aber doch immer wieder mal Probleme mit C die ich in Pascal nicht habe.
Mal abgesehen davon, dass es bei C99 wohl 190 Fälle gibt, wo nicht vorgeschrieben ist was der Compiler daraus machen soll...
Muste ich natürlich mit in meine Risikoanalyse aufnehmen....
https://www.elektronikpraxis.vogel.d...che-c-a-426198

Mich würde ja mal interessiren um welche Fälle es sich da handelt, falls da jemand Informationen oder Links zu hat, wäre ich sehr dankbar.

Zum Problem mit den Redistributablen von Microsoft:
Ich war mal, wie immer, experimentierfreudig ich habe die gesamten Microsoft Redistributables deinstalliert.....
Ältestes zuerst bis zum Aktuellsten.
Das Letzte liess sich nicht entfernen, vielleicht braucht das Windows selbst, keine Ahnung.
Aber nun konnte ich problemlos meine RIGOL Software installieren, was voher nicht ging.
Ich hatte übrignes nach der Deinstallation diverse Programme ausprobiert, ob sie davon betroffen sind.
OpenOffice
FireFox
Eagle
MCUXPresso
MPLAB
LAZARUS
keiner hatte Probleme, aber es war, wie gesagt, noch eine letzte Version vorhanden von 2017
viel mehr an Software läuft auch nicht auf meinem Rechner.

wenn ich jetzt sagen sollte, die Rigol Software läuft gut, müste ich lügen.
Das Bild auf dem Rechner entspricht nicht dem auf dem Oszilloskop Bildschirm.....Ohje.....
Wenn man das Programm verlässt und neu startet stimmt es wieder. Man darf nix am Ossi ändern, das bekommt die Software am PC anscheinend nicht mit.
Ist nicht perfekt, aber brauchbar...



Siro

[Ceos]

Mal abgesehen davon, dass es bei C99 wohl 190 Fälle gibt, wo nicht vorgeschrieben ist was der Compiler daraus machen soll...
Muste ich natürlich mit in meine Risikoanalyse aufnehmen....

Und das ist der Grund warum wir hier auf Arbeit keine schönen Dinge haben können (TM)

Wir haben Guidelines die uns gewisse Dinge verbieten ... So viele schöne Kontrukte die man bauen kann aber dann kommt der "nein das darfst du nicht"-Hammer weil "offsetof" nicht sauber spezifiziert ist

... und solch ähnliche Späße

Habe mir eine Standpauke über X-Makros anhören müssen .... mimimi statische Codeanalyse kann keine Functionpointer in Arrays verfolgen mimimi .... gut, jetzt ists halt ein ebenfalls per X-Makro generierter riesen-switch-case statt einer Spungtabelle ... der Compiler baut eh wieder ne Sprungtabelle draus aber wenigstens kann die statise Code analyse das jetzt verarbeiten

[Siro]

Moin Ceos
Ist doch mal schön zu hören, dass ich nicht der Einzige bin, der nach diversen Regeln arbeiten soll...
Wobei ich glücklicherweise NOCH keine wirklichen Vorgaben habe wie ich was implementiere.
Der Compiler macht eh was er will, das kann man kaum steuern.
Die wirklichen Probleme einer nicht funktionierenden Software liegen oftmals völlig woanders.
Das ist auch der Grund warum ich stets mit verschiedenen Optionen compiliere und teste.
Es finden sich immer wieder neue Merkwürdigkeiten, die oft sogar mit der Prozessorarchitektur zusammen hängen.
Das kann eh keine automatische Codeanlayse feststellen.

Ich habe auch Funktionstabellen, weil es wesentlich Übersichtlicher ist als ein switch-case.

"offsetof" kannte ich noch garnicht, witzigerwiese scheint das genau das zu sein, was ich für meine
EEPROM struktur verwende....
Was soll daran nicht "sauber" bzw. nicht nachvollziehbar sein ?

Im eeprom bei mir liegt ein struct, wo welcher Wert liegt ist nicht direkt bekannt, aber man kann es berechnen:

t_ee_struct *p;

  /* we dont know where the userdata is stored in the EEPROM */
  /* but we can calulate the address: */
  p = 0;  /* think the struct starts at address 0 */
  /* convert the pointer to a 32 Bit value (EE-ADDRESS) with the offset of setup_data */
  ee_address = (U32)(&p->setup_data);


// Deine genannte Variante mit offsetof  sieht doch VIEL besser aus, muss ich direkt mal ausprobieren .....
  ee_address = offsetof(ee_data,setup_data);

das macro hab ich grad gesichtet:

#define offsetof(struct_type, member) \
          (size_t) &(((struct_type *)0)->member)

Siro