Lemon Sented wrote:
> Visual Studio .NET is not free, is a gargantuan resource consumer
> (1-2GB install, 50MB+ running), is incredibly slow, takes 10 minutes
> to load on a 2GHz+512MB machine, and, worst of all, makes you use the
> mouse for almost everything.

Well! Chipmakers should love to hear that.

10 minutes, at 2GHz. That's 1200000000000 lines of assembler code.

Every now and then I get the feeling Bill is joking. On us.

In article <d2s9oi$49g$1@digitaldaemon.com>, Lemon Sented says...
>
>Visual Studio .NET is not free, is a gargantuan resource consumer (1-2GB install, 50MB+ running), is incredibly slow, takes 10 minutes to load on a 2GHz+512MB machine, and, worst of all, makes you use the mouse for almost everything.
>
>So, I'd suggest you *do* use VC++, but that you *do not* buy any of the Visual Studio stuff.

On my 1.4GHz laptop with 512MB RAM Visual Studio .NET 2003 loads in 14 seconds if I start it up after using the OS for a while (ie. if Windows has to dump stuff into swap space while loading the app) and in 2 seconds otherwise.  It is fairly fast to use, and can be extremely fast if you take the trouble to disable some of the IntelliSense stuff.  Finally, there are key combinations for everything--I never take my hands off the keyboard while using Visual Studio.  I know some people aren't much for IDEs, but in the IDE world it's by far the best I've come across.  If I had to voice one major complaint about the MS development suite it would be about that travesty of a version control system, Visual SourceSafe.  I'm overjoyed that they're getting rid of it for the next big Visual Studio release.

But this is a D forum so the above is really neither here nor there :)  That is, unless someone has figured out how to inspect variables while debugging a D application using Visual Studio or the MS standalone debugger.


Sean

There's also a wide version (wchar_t) of fopen, but as they are non-standard, microsoft adds some strange prefixes to its name that I can't seem to remember, _wfopen or something, I dunno.

And I suppose the unicode in Windows is UTF-16 since Windows supports unicode aggregates?

L.

"Benjamin Herr" <ben@0x539.de> wrote in message news:d2sbag$6b4$1@digitaldaemon.com...
> Lionello Lunesu wrote:
>> I've just installed .NET 2005 februari preview release and tried to
>> compile
>> my current projects (made using VC6), and got thousands of these:
>>
>> warning C4996: 'fopen' was declared deprecated
>
> Hm. I assume that the WinAPI comes with evil functions to open files by UTF-16 names, and that fopen cannot take UTF-16 strings and thus not open all files, so it is quite inaquedate for Windows.
>
> What am I missing?
>
> --Benjamin

Hi,

>> warning C4996: 'fopen' was declared deprecated
>>
>> In fact, all methods taking a zero-terminated string are deprecated and for those that don't have a version taking a size_t, a new method ending in _s (fopen_s) was added, taking an extra size_t for the size of the string.
>>
>> This was done to cut back on buffer-overflow hacks, obvisously.
>
> Hmmm. Since such functions are standard, how can they be deprecated? A very perverse take on reality.

Microsoft decides what you call reality, don't you get it?

> Also, UNIX/Mac systems are written in standard C and, though they do have/have had security issues with overflows, they're hardly in the Windows league. Maybe it's not just the standard library functions???

I bet it's not. I wonder if the Win32 API methods lstrcpy and lstrcat are deprecated too :-)

>> I'd say the whole CRT/libc stuff should be deprecated in D. Phobos should be a library using only D. If you're porting a C/C++ project, you'll link to some crt.d files, but I believe they should not be a part of Phobos. Lets get rid of those zero-terminated strings once and for all.
>
> That's an interesting take. Clean delineation of abstraction levels is a good thing, but not always a popular one.

Again with the ugly: I think the C standard library is ugly. fputs(string, FILE*) and fprintf(FILE*, string, ..) oh come on.

L.

>>warning C4996: 'fopen' was declared deprecated
>>
>>In fact, all methods taking a zero-terminated string are deprecated and
>>for
>>those that don't have a version taking a size_t, a new method ending in _s
>>(fopen_s) was added, taking an extra size_t for the size of the string.
>
> Great, now I'll have another warning to add to my ignore list.  I think
> the VC++
> team tends to be one of the best at that company, but how they can
> deprecate
> functions required by the standard is beyond me.

To make you use .NET? That'll be the end of VC++.

>>This was done to cut back on buffer-overflow hacks, obvisously.
>
> Indeed.  But is it really necessary to do this just because the folks at Microsoft can't write secure code?

Yeah. They should have sticked to a segmented memory model so no code could even get executed on the stack in the first place... I get the impression they're selling this 80286 feature on P4/AMD64 as "data execution prevention" or something...

>>I sooo want to program in D, but I can't really get even a simple project finished (I'm converting FART to D, http://fart-it.sf.net/ )
>
> What's wrong?

Well, first of all it's Phobos. On one side you have C runtime library-like functions, on the other side there are Stream, writef. And I'm trying to use only one of these 'apis'. I prefer using "the new way of doing things", but I have to get used to it all over again, get to know all the classes, functions.

The next problem is that I want to redesign it completely, make it OOP, using interfaces, so that FART can be embedded in other applications. Splitting the console app FART in command line interpreter, recls, fart core, console output. Something like that, still not too clear though.

L.

Oops, my bad:

fopen_s(FILE **, const char *, const char *);

It seems it's not the string that they're afraid of, but the FILE*. Indeed, no memory would get overwritten if the filename or open-specifier are illegal or too long..

L.

Word!

In article <d2s9oi$49g$1@digitaldaemon.com>, Lemon Sented says...
>
>> If I were to spend like $800, I would probably get CodeWarrior. But then again, I probably am not - and just use GCC instead...
>
>
>Visual C++ 7.1 cmd line tool set is free, and is a *very* good compiler, in my personal best 3 (along with Intel and CodeWarrior; GCC is a close 4th).
>
>Visual Studio .NET is not free, is a gargantuan resource consumer (1-2GB install, 50MB+ running), is incredibly slow, takes 10 minutes to load on a 2GHz+512MB machine, and, worst of all, makes you use the mouse for almost everything.
>
>So, I'd suggest you *do* use VC++, but that you *do not* buy any of the Visual Studio stuff.
>
>
>

>
> I sooo want to program in D, but I can't really get even a simple project finished (I'm converting FART to D, http://fart-it.sf.net/ )
>


What are the issues?

Thanks,

- Dave

I want to use only D stuff from Phobos. I mean, I don't want to encounter any pointer whatsoever, so no crt/libc stuff. The biggest problem is that I have to get use to the classes.

Furthermore, I want to split the project in sub-projects: a FART-core that does the actual magic, a command-line interpreter and a console output 'front-end' for the console program.

Maybe I'm trying to do too many things at once..

L.

"Dave" <Dave_member@pathlink.com> wrote in message news:d2uarn$277n$1@digitaldaemon.com...
> >
>> I sooo want to program in D, but I can't really get even a simple project finished (I'm converting FART to D, http://fart-it.sf.net/ )
>>
>
>
> What are the issues?
>
> Thanks,
>
> - Dave
>
>