Win98 Bug?

Bug reports for an official AniDB Client go here

Moderators: AniDB, AniDB API

Locked
KnightAR

Win98 Bug?

Post by KnightAR »

Image

This is what I get when I'm starting the client. I'm running it on my laptop, It's a Win98 system with 48mb's ram, 2 gig hd (700mb free), .Net Frame 1.1. It's about a 120mhz system.

HELP!

Thanks
[/img]
Hisoka
Posts: 11
Joined: Fri May 30, 2003 9:25 am
Location: Berlin - Germany

System Requirements ... if there's such a thing ...

Post by Hisoka »

well.... jep .... i think i know what this is all about ... well
anidbclient alone takes up ~24 mb ram while running ...
i wonder how the hell u got .net running in such a box but
i don't think u'll get any .net application running sorry ...

cya
Hisoka[]
DonGato
Posts: 1296
Joined: Sun Nov 17, 2002 9:08 pm
Location: The Pampas, The land of the Gaucho!
Contact:

Post by DonGato »

Another good point to leave .NET development in the past. ;)
kidan
Posts: 319
Joined: Thu Feb 13, 2003 9:13 pm
Location: .DE

RAM .NET

Post by kidan »

:idea: A .NET-application needs this much ram, as it instances the CLR, which is a big classlibrary of about 20 MB. Java does just the same (but with a far smaller classlib with far less features).By the way winsock-coding with C++ is a real pain in the ass, so i guess the anidb-client would never really pass alpha-stage.
Imho c++ should no more be used for user apps, except you really know what you are doing, as it produces allmost all bufferoverflows = security holes. If performance is that important, you should use w32-assembler.
DonGato
Posts: 1296
Joined: Sun Nov 17, 2002 9:08 pm
Location: The Pampas, The land of the Gaucho!
Contact:

Post by DonGato »

Well, C++ is THE language to be used for professional applications. Assembler is not easy to code it so it is only used when high performance is needed.

.NET is proprietary and not ready for mass usage. I don't see any critical application running in .NET. Java isn't intended for this kind of applications but J2EE is the best platform for back-end applications.

There are lots of other languages not CLR based better for this kind of applications.

The problem here is not performance but COMPATIBILITY, and the best for that is C++ plain and simple (even without using MFC). ;)
Hisoka
Posts: 11
Joined: Fri May 30, 2003 9:25 am
Location: Berlin - Germany

so c++ without mfc ... yeah ryt j0000

Post by Hisoka »

well if you like to have an client: fast stable good looking full of xtravagant
super features and written in plain c++ or assembler ....

GO WRITE ONE YOURSELF

cya Hisoka[]
DonGato
Posts: 1296
Joined: Sun Nov 17, 2002 9:08 pm
Location: The Pampas, The land of the Gaucho!
Contact:

Post by DonGato »

I'm being real here. The time you will spend trying to fix technology bugs could be spent in using another language more stable than this one but I don't really care as I stated that having a client it is a stupid thing IMO and that a web site is all I need. So go play with your client and I will use the well written web site. ;)
PetriW
AniDB Staff
Posts: 1522
Joined: Sat May 24, 2003 2:34 pm

Post by PetriW »

.NET will probably have it's following, I myself am a delphi programmer, whenever I write something in another I wish I could do it in delphi instead since I like the language better. :D
C++ has plenty of bad sides, delphi has it's own too and .NET prolly have a metric fuckton of them but if someone feels more comfortable writing an application for anidb and is willing to spend the time doing so at least let them choose. :)
kidan
Posts: 319
Joined: Thu Feb 13, 2003 9:13 pm
Location: .DE

Post by kidan »

DonGato wrote:Well, C++ is THE language to be used for professional applications. Assembler is not easy to code it so it is only used when high performance is needed.
In my opinion far too many people code c++ without enough knowledge about assembler. This really is a bad thing, as c++ does almost nothing to prevent major security and memory leaks. It is a language only a few pros should use when writing hardware-based code, but not user applications. C++ has no built in support for any http-sevices thus making it a bad choice for a client, which should connect to a database via http. The .NET dataset is a container especially designed to handle async-db access via http and xml.
DonGato wrote: .NET is proprietary and not ready for mass usage. I don't see any critical application running in .NET. Java isn't intended for this kind of applications but J2EE is the best platform for back-end applications.
Some major webpages are using .NET (aspx) and I'm coding quite regulary in VB.NET as it is a clean language, which gives you high performance with an intuitive syntax. No need for pointers (most people cannot use their advantages anyways, but take their risks) and great IDE (VStudio.NET) which makes debugging far easier.
DonGato wrote:The problem here is not performance but COMPATIBILITY, and the best for that is C++ plain and simple (even without using MFC). ;)
.NET is very compatible, as it uses a standarised set of variable-types and for communication over the net it uses SOAP, which is also a open standard based on XML. It is not hard to get .NET interop with JAVA or COM because of this.

Anyways it is personal preference, if you like comfort or not. If I'd have to choos beetween NortonCommander and a DOS-shell I'd take the Norton for allmost all purposes.
Locked