What language was windows XP built using ?

[J32P2006]

Sorry I'm very stupid when it comes to programming. But I was wondering what language was windows XP built using ? I've heard C++ , but just want to make sure ?

 

[HHunt]

There's a lot of C++, I'm sure there's some C (kernel stuff), and probably a few others as well. I wouldn't be suprised if there's a bunch of VBScript or something like it driving some of the wizards.

 

[ameoba]

don't forget assembly in parts of low-level OS stuff and device drivers

 

[enlightenedby42]

Actually in an assembly class right now and we've talked about it.
Really low level stuff is done in assembly, the rest in C or C++ (probably C++ lately). C++ is actually directly analagous to assembly, but you do not have as much precise control over efficency and things of that nature. Windows, 'nix, all those are built in that way from what I understand. Cool stuff.
Anybody who has had to take assembly knows why they use high level languages as early in the process as possible. Assembly can be harder than a left turn downtown sometimes.

 

[ekliptikz]

french

 

[J32P2006]

Thanks for the info guys

 

[ekliptikz]

always a pleasure

 

[J32P2006]

always a pleasure

Thank you especially. So what language was french made in C++?

 

[KingKaeru]

always a pleasure

Lets all stay on topic as this is not the General Mayhem forum.

--KK

 

[HHunt]

Actually in an assembly class right now and we've talked about it.
Really low level stuff is done in assembly, the rest in C or C++ (probably C++ lately). C++ is actually directly analagous to assembly, but you do not have as much precise control over efficency and things of that nature. Windows, 'nix, all those are built in that way from what I understand. Cool stuff.
Anybody who has had to take assembly knows why they use high level languages as early in the process as possible. Assembly can be harder than a left turn downtown sometimes.

I haven't had an assembly class, but I've meddled with it [1]. It makes you appreciate higher-level languages, but more importantly it makes you consider what your C code ends up doing. (It also helps that a classmate of mine likes to use m68k-assembler for explaining everything. He's an amiga guy that just barely tolerates other architectures and OSes.)

It's very fascinating to look at the assembly output from a compiler, btw. They use some really arcane stuff.
(For a simple example, it's faster to xor a register with itself than to write a zero to it, at least on x86. On alpha you can copy from r0, which is always 0, but I'm not sure if that's faster or not.)

[1] Alpha instead of x86, since I happened to have one around. It's a nice processor, though the stack handling is simpler on x86. Lots of registers, 64-bit.

 

[enlightenedby42]

Yeah dude, the bitwise operators are pretty interesting. There is simply no faster way for a computer to do math, 'cuz you're literally "speaking its language" if you'll pardon the pseudo-pun. You can even use them for

My prof. wrote about a dozen instruction c-callable assembly function to replace the log function in the cmath library and timed them both calculating a million or so logs, and the assembly function was almost 3x faster! Makes you question the efficiency of included functions a bit.

Its been pretty interesting stuff, but actually writing assembly programs can really be a drag, particularly with a teacher that isn't very thorough in explaining things. I'm going to be like a pig in shit when I get to a high level language again. Ah, the eloquence of a well written loop free of linear jumps. Promised land, here I come.

 

[ameoba]

My prof. wrote about a dozen instruction c-callable assembly function to replace the log function in the cmath library and timed them both calculating a million or so logs, and the assembly function was almost 3x faster! Makes you question the efficiency of included functions a bit.

...or what he left out.

 

[Xipher]

Mostly ASM is only for the required low level stuff any more, since the average compiler can pump out better code on average then a human, and much faster at it too.

 

[enlightenedby42]

...or what he left out.

Hah, too true. Actually in this particular case I believe that was handling of really big/really weird numberrs. But, nevertheless. I, for one, am gonna let the compiler handle it for me, that's for damn sure.

 

[enlightenedby42]

Also, from what I understood, some of the increased efficency is (again, could be wrong here) due to the fact that c++ pushes and pops all the registers at the beginning and end of the function, respectively.
Anyway, mea culpa for getting off topic a bit here. At least I'm still talking about programming.

 

[bassman]

Mostly ASM is only for the required low level stuff any more, since the average compiler can pump out better code on average then a human, and much faster at it too.

Very true. There are many things compilers are much better at optimizing. Like using pairable instructions (Pentium and later processors have 2+ pipes) and minimizing the effects of branch prediction gone bad (especially important in Pentium 4 because of the long pipeline). Not to mention programs written in high-level languages are MUCH easier to write and maintain. That means better software faster, which means lower costs for software development.

 

[HHunt]

I would guess that most of the ASM written today is for
1) things that can't be done any other way (Some parts of the taskswitching code in FreeBSD, for instance), and
2) Performance in very specific situations. (The SSE and MMX code in mplayer is handwritten, IIRC. Same for the code to zero a page of memory in FreeBSD.)

Compilers don't seem to be quite as good as people at wringing the most out of SSE yet.

 

[BillLeeLee]

Well, that could be attributed to the code generation done by compilers, and code generation is not perfected in anyway. If you have some specific purpose, coding special assembly for it might be better. My compilers professor discussed how he and his team rolled their own assembly so their code would score higher on Dhrystone benchmarks.

Speaking of ASM - I like MIPS assembly. Really beats the pants off X86 (4 general purpose registers...).

 

[dx2]

french

lol

 

[mikeblas]

Also, from what I understood, some of the increased efficency is (again, could be wrong here) due to the fact that c++ pushes and pops all the registers at the beginning and end of the function, respectively.

C++ doesn't push and pop all registers; only the registers it needs. And it only does that when you don't ask it to do something different. VC++ supports different calling conventions, like __fastcall, which endeavor to put all the args in registers. The use and management of registers isn't standardized by the language, so whatever happens is up to the implementation of the compiler.

When you write assembly, you might be able to avoid saving and restoring registers at each function. But that's dicey business, since you'll need the register values in the function and you don't want to get into the practice remembering which registers are trashed and which ones aren't. It's possible to do for small programs, sure -- but it doesn't scale to any interesting project size or larger team size.

When I first saw the original post, by the way, I though it was a question about what language was used to build Windows. That is, which scripting language kicks off the compiler to compile all the code in the product. At Microsoft, most every team builds their product end-to-end every day.

Building tens of millions of lines of code, with different options (debug, release), targeting different UI-languages (twelve or fifteen, these days for Windows, I think), different platforms (IA64, x64, IA32), obviously isn't a trivial task. The build labs for larger products have a lot of hard work to do. They use a combination of some custom tools, batch files, script lnaguages like VBScript and Perl, and of course NMAKE.

 

[fluxion]

Also, from what I understood, some of the increased efficency is (again, could be wrong here) due to the fact that c++ pushes and pops all the registers at the beginning and end of the function, respectively.
Anyway, mea culpa for getting off topic a bit here. At least I'm still talking about programming.

C++ tosses out some pretty shitty code sometimes actually. take this C++ code for a bubblesort, for example:

void BubbleSort(int data[], int count, int dir) {
    bool done = false;
    while(!done) {
        done = true;
        for(int i=0;i<count-1;i++) {
            bool swap;
            if(dir == 0) {
               swap = data[i] > data[i+1];
            }
            else {
                swap = data[i] < data[i+1];
            }
             if(swap) {
                int temp = data[i];
               data[i] = data[i+1];
               data[i+1] = temp;
               done = false;
            }
        }
    }
}

probably room for optimization, but fairly straightforward right? here's the ASM VC++ compiler generates from the above source:

PUBLIC	?BubbleSort@@YAXQAHHH@Z				; BubbleSort
;	COMDAT ?BubbleSort@@YAXQAHHH@Z
_TEXT	SEGMENT
_data$ = 8
_count$ = 12
_dir$ = 16
_done$ = -4
_i$276 = -8
_swap$280 = -12
_temp$284 = -16
?BubbleSort@@YAXQAHHH@Z PROC NEAR			; BubbleSort, COMDAT

; 3    : void BubbleSort(int data[], int count, int dir) {

	push	ebp
	mov	ebp, esp
	sub	esp, 80					; 00000050H
	push	ebx
	push	esi
	push	edi
	lea	edi, DWORD PTR [ebp-80]
	mov	ecx, 20					; 00000014H
	mov	eax, -858993460				; ccccccccH
	rep stosd

; 4    :     bool done = false;

	mov	BYTE PTR _done$[ebp], 0
$L274:

; 5    :     while(!done) {

	mov	eax, DWORD PTR _done$[ebp]
	and	eax, 255				; 000000ffH
	test	eax, eax
	jne	$L275

; 6    :         done = true;

	mov	BYTE PTR _done$[ebp], 1

; 7    :         for(int i=0;i<count-1;i++) {

	mov	DWORD PTR _i$276[ebp], 0
	jmp	SHORT $L277
$L278:
	mov	ecx, DWORD PTR _i$276[ebp]
	add	ecx, 1
	mov	DWORD PTR _i$276[ebp], ecx
$L277:
	mov	edx, DWORD PTR _count$[ebp]
	sub	edx, 1
	cmp	DWORD PTR _i$276[ebp], edx
	jge	$L279

; 8    :             bool swap;
; 9    :             if(dir == 0) {

	cmp	DWORD PTR _dir$[ebp], 0
	jne	SHORT $L281

w00t!! in actuallity i guess it's not a bad translation, but viewing the source in the context of ASM it becomes readily apparent that there's a ton that can be done to increase efficiency, namely by using the registers more efficiently. here's what i came up with, which is probably still far from optimal:

PUBLIC	BubbleSort
_TEXT SEGMENT
_data$ = 8
_count$ = 12
_dir$ = 16
_done$ = -4

BubbleSort PROC NEAR
	push	ebp
	mov	ebp, esp
	sub	esp, 8
	push eax
	push ebx
	push ecx
	push esi
	push edi
	mov ecx, [_data$+ebp]
	mov edx, _dir$[ebp] ;direction indicator
bsSwapAgain:
	mov DWORD PTR _done$[ebp], 1
	mov esi, 0 ;array index
bsArrayLoop:
	cmp edx, 0
	jne bsSwapBackward

	mov eax, [ecx+esi*4] ;data[i]
	mov ebx, [ecx+esi*4+4] ;data[i+1]
	sub ebx, eax
	jns bsIterate ;skip if data[i] !> data[i+1]
	mov ebx, DWORD PTR [ecx+esi*4+4] ;data[i+1]
	mov [ecx+esi*4], ebx ;data[i] = data[i+1]
	mov [ecx+esi*4+4], eax ;data[i+1] = data[i]
	mov DWORD PTR _done$[ebp], 0
	jmp bsIterate
bsSwapBackward:
	mov eax, [ecx+esi*4] ;data[i]
	mov ebx, [ecx+esi*4+4] ;data[i+1]
	sub eax, ebx
	jns bsIterate ;skip if data[i] !> data[i+1]
	mov eax, [ecx+esi*4] ; data[i]
	mov [ecx+esi*4], ebx ;data[i] = data[i+1]
	mov [ecx+esi*4+4], eax ;data[i+1] = data[i]
	mov DWORD PTR _done$[ebp], 0
bsIterate:
	inc esi
	mov eax, _count$[ebp]
	dec eax
	cmp esi, eax
	jne bsArrayLoop

	mov eax, _done$[ebp]
	cmp eax, 0
	je bsSwapAgain

	pop edi
	pop esi
	pop ecx
	pop ebx
	pop eax
	mov esp, ebp
	pop ebp
	ret 0
BubbleSort ENDP
_TEXT	ENDS
END

Sorting times with VC++:
Time to sort 100 items 1000 times is 0.109 seconds
Time to sort 200 items 1000 times is 0.532 seconds
Time to sort 300 items 1000 times is 1.187 seconds
Time to sort 400 items 1000 times is 2.141 seconds
Time to sort 500 items 1000 times is 3.438 seconds
Time to sort 600 items 1000 times is 4.797 seconds
Time to sort 700 items 1000 times is 6.609 seconds
Time to sort 800 items 1000 times is 8.5 seconds
Time to sort 900 items 1000 times is 10.938 seconds
Time to sort 1000 items 1000 times is 13.547 seconds

Sorting times with ASM:
Time to sort 100 items 1000 times is 0.046 seconds
Time to sort 200 items 1000 times is 0.188 seconds
Time to sort 300 items 1000 times is 0.391 seconds
Time to sort 400 items 1000 times is 0.734 seconds
Time to sort 500 items 1000 times is 1.141 seconds
Time to sort 600 items 1000 times is 1.578 seconds
Time to sort 700 items 1000 times is 2.172 seconds
Time to sort 800 items 1000 times is 2.796 seconds
Time to sort 900 items 1000 times is 3.563 seconds
Time to sort 1000 items 1000 times is 4.516 seconds

basically sped it up by a factor of 3 without compromising any functionality

 

[mikeblas]

C++ tosses out some pretty shitty code sometimes actually. take this C++ code for a bubblesort, for example:
[...]
probably room for optimization, but fairly straightforward right? here's the ASM VC++ compiler generates from the above source:

Which command-line options did you give the compiler? Looks like you've also forgotten to paste the rest of the output -- some of the interesting parts are missing.

When I build your function with /Ox, I get substantially better output than you're quoting here; it's pasted below. I think you forgot to ask the compiler to do any optimizations -- it isn't enregistering anything at all. Another giveaway that you're looking at an unoptimial code is in the preamble -- looks like you've got /RTC1 on, which isn't something that someone would do when they're looking for the compiler to generate optimal code.

As such, your benchmark results are suspect -- I don't think anyone can use them for any sort of conclusions.

Meanwhile, the code you wrote by hand is, indeed, not really optimal. You're not doing anything at all for instruction ordering, for example. Worse, you're double-pumping memory.

; Listing generated by Microsoft (R) Optimizing Compiler Version 14.00.50727.42 

	TITLE	C:\sort.cpp
	.686P
	.XMM
	include listing.inc
	.model	flat

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC	?BubbleSort@@YGXQAHHH@Z				; BubbleSort
; Function compile flags: /Ogtpy
; File c:\sort.cpp
_TEXT	SEGMENT
_data$ = 8						; size = 4
_count$ = 12						; size = 4
_dir$ = 16						; size = 4
?BubbleSort@@YGXQAHHH@Z PROC				; BubbleSort

; 1    : void BubbleSort(int data[], int count, int dir) {

  00000	53		 push	 ebx
  00001	55		 push	 ebp
  00002	8b 6c 24 10	 mov	 ebp, DWORD PTR _count$[esp+4]
  00006	56		 push	 esi
  00007	57		 push	 edi
  00008	8b 7c 24 14	 mov	 edi, DWORD PTR _data$[esp+12]
  0000c	83 c5 ff	 add	 ebp, -1
  0000f	90		 npad	 1
$LL8@BubbleSort:

; 4    :         done = true;
; 5    :         for(int i=0;i<count-1;i++) {

  00010	33 f6		 xor	 esi, esi
  00012	85 ed		 test	 ebp, ebp
  00014	b3 01		 mov	 bl, 1
  00016	7e 3a		 jle	 SHORT $LN14@BubbleSort
  00018	eb 06 8d 9b 00
	00 00 00	 npad	 8
$LL15@BubbleSort:

; 6    :             bool swap;
; 7    :             if(dir == 0) {

  00020	83 7c 24 1c 00	 cmp	 DWORD PTR _dir$[esp+12], 0

; 8    :                swap = data[i] > data[i+1];

  00025	8b 04 b7	 mov	 eax, DWORD PTR [edi+esi*4]
  00028	8b 4c b7 04	 mov	 ecx, DWORD PTR [edi+esi*4+4]
  0002c	75 07		 jne	 SHORT $LN3@BubbleSort
  0002e	3b c1		 cmp	 eax, ecx
  00030	0f 9f c2	 setg	 dl

; 9    :             }
; 10   :             else {

  00033	eb 05		 jmp	 SHORT $LN2@BubbleSort
$LN3@BubbleSort:

; 11   :                 swap = data[i] < data[i+1];

  00035	3b c1		 cmp	 eax, ecx
  00037	0f 9c c2	 setl	 dl
$LN2@BubbleSort:

; 12   :             }
; 13   :              if(swap) {

  0003a	84 d2		 test	 dl, dl
  0003c	74 09		 je	 SHORT $LN5@BubbleSort

; 14   :                 int temp = data[i];
; 15   :                data[i] = data[i+1];

  0003e	89 0c b7	 mov	 DWORD PTR [edi+esi*4], ecx

; 16   :                data[i+1] = temp;

  00041	89 44 b7 04	 mov	 DWORD PTR [edi+esi*4+4], eax

; 17   :                done = false;

  00045	32 db		 xor	 bl, bl
$LN5@BubbleSort:
  00047	83 c6 01	 add	 esi, 1
  0004a	3b f5		 cmp	 esi, ebp
  0004c	7c d2		 jl	 SHORT $LL15@BubbleSort

; 2    :     bool done = false;
; 3    :     while(!done) {

  0004e	84 db		 test	 bl, bl
  00050	74 be		 je	 SHORT $LL8@BubbleSort
$LN14@BubbleSort:
  00052	5f		 pop	 edi
  00053	5e		 pop	 esi
  00054	5d		 pop	 ebp
  00055	5b		 pop	 ebx

; 18   :             }
; 19   :         }
; 20   :     }
; 21   : }

  00056	c2 0c 00	 ret	 12			; 0000000cH
?BubbleSort@@YGXQAHHH@Z ENDP				; BubbleSort
_TEXT	ENDS
END

 

[mikeblas]

I worked through lunch on a better assembler version. I think I'm there; I'm not sure if I can get anything else out of it (aside from aligning branch targets). The code is up at http://www.blaszczak.com/posts/FastBubbles.ZIP, if you're interested in seeing it. (The code is provided without warranty and confers no rights.)

On different machines, I found that different implementations were faster or slower. I guess that's not surprising, but the order they finish here doesn't change much anyhwere.

I used a dual-proc Xenon 2.4 GHz machine. Here's the results for an array of 10,000 integers:

Baseline: 0.4968
Baseline Tweaked: 0.3637
Baseline unoptimized: 1.011
Fluxion Assembly: 0.4643
Mikeblas Assembly: 0.3672
Mikeblas2 Assembly: 0.3405
Quicksort: 0.00245

The baseline version is what fluxion posted in C++. (Well, C, really.) Tweaked includes some source-code fixes I made without changing the actual algorithm. Unoptimized is a version where optimizations in the compiler are turned off; what I figure fluxion was comparing with in his post.

Fluxion's assembly is there, as are two versions of my own assembler code. The times listed are in seconds, timed with QueryPerformanceCounter().

Quicksort is the CRTL-provided sort. It's not so great, since it calls through a function pointer to the comparison routine. That can't be inlined, and so it is expensive. The VC++ implementation doesn't use any of the popular optimizations.

Of course, nobody should forget that the algorithm is usually far more important than its implementation. If you code up something that sucks in assembler, it's still going to get spanked by C++ version of a better algorithm. On my dual Xenon 2.4 machine, I upped the item count in the arrays to 250,000, and got these numbers. No surprise that quicksort is still faster!

Baseline: 356.5
Baseline Tweaked: 302.5
Baseline unoptimized: 658.1
Fluxion Assembly: 334.7
Mikeblas Assembly: 292.8
Mikeblas2 Assembly: 286.4
Quicksort: 0.06908

And sorry to be all over it -- I can't resist an optimization challenge. Since it's what I do at work all day, anything that comes along is an interesting departure.

 

[enlightenedby42]

Damn, that was extrordinarily educational guys. Cool stuff.

 

[fluxion]

haha, very nice mikeblas. i know it wasn't a very good benchmark, and i didn't use any optimizations or anything with vc++. my main point was to address the insinuation that for assembly code to outpace it's C++ equivalent by a factor of 3 the code must have been crippled in some respect. an assembly newb like me hitting near that very mark while retaining functionality seemed like a good counterpoint (although the optimized vc++ output you posted would probably yield a drammatic performance increase).

great post though, you really cleaned up the assembly code there. add 4 to esi instead of multiplying increments of 1 by 4 all the time...i'm slapping my forehead right now lol. lesson here is that there's always room for improvement

 

[svet-am]

to make a quick run back at the OP's questions, here's a quick enumeration of the languages used in the development of Windows XP (and most MS Windows these days):

x86 Assembly (for low level kernel stuff and device drivers)
ANSI C (again, for the low-level stuff)
C++ (general Windows API stuff like MFC, DirectX, etc)
XML (windows uses XML a lot for controlling display for a lot of COM apps)
HTML (see XML)


With the advent of Windows Vista, we're also going to see an additional language used in the MONAD scripting language as it becomes an integral part of the OS and takes on some routine system-upkeep duties

 

[mikeblas]

haha, very nice mikeblas. i know it wasn't a very good benchmark, and i didn't use any optimizations or anything with vc++. my main point was to address the insinuation that for assembly code to outpace it's C++ equivalent by a factor of 3 the code must have been crippled in some respect. an assembly newb like me hitting near that very mark while retaining full functionality seemed like a good counterpoint.

Er, maybe I'm misunderstanding you -- but the compiler-generated code you were comparing against was crippled. The only reason that the compiler "tossed out shitty code" was because you explicitly asked to to not optimize anything at all. The code you had it generate was plain and simple, and therefore easy to debug. There's even defensive stuff in there -- painting the stack with a pattern so uninitialized variables can be detected. Since you call the routine 1000 times in your test, that overhead adds up.

Turning on optimizations got the compiler to within ten percent of your hand-written code. Making some simple source-level tweaks had the compiler generating code that was faster than your assembly.

Oh -- did you mean that the assembler version must have been cripped by removing features to become faster?

great post though, you really cleaned up the assembly code there. add 4 to esi instead of multiplying increments of 1 by 4 all the time...i'm slapping my forehead right now lol. lesson here is that there's always room for improvement

Well, the real wins come from touching memory less. You would reload values you recently had since you used SUB instead of CMP. Going to memory is very expensive because memory is very slow. Branching in every loop iteration based on the direction being sorted is also expensive -- since that's invariant, hoisting it out of the loop makes a lot of sesne.

The multiplied addressing mode isn't all that expensive. The processor implements it with a barrel shifter, so it only adds a few cycles to the instruction. It does make the instruction longer, though, and doing it O(n*n) times has a cumulative effect.

These optimizations are what I applied to the C version of the routine to go from "Baseline" to "baseline tweaked". With only a few exceptions, the compiler does what you ask it to do, and slow code is slow independent of the language.

A slow algorithm is even worse. Quicksort is about 4000 times faster for the larger dataset. How patient would you be with a program that took five minutes to run? But something that completes in 70 mS or so is not even noticable. A ten percent difference is a cheap processor upgrade away -- some people overclock by that much. But it'll be a while before we have processors that are 400,000% faster in a single thread.

 

[J32P2006]

I just wanted something like this...

x86 Assembly (for low level kernel stuff and device drivers)
ANSI C (again, for the low-level stuff)
C++ (general Windows API stuff like MFC, DirectX, etc)
XML (windows uses XML a lot for controlling display for a lot of COM apps)
HTML (see XML)

Thanks for all the input though. Holy shit, becareful of what you ask for.

And i'm having trouble learning visual basic 6.

 

[fluxion]

Oh -- did you mean that the assembler version must have been cripped by removing features to become faster?

yah, i meant that the assembly code didn't necessarilly have to sacrafice functionality (be crippled) to be faster.

thanks for the info though

 

[HHunt]

I just wanted something like this...



Thanks for all the input though. Holy shit, becareful of what you ask for.
And i'm having trouble learning visual basic 6.

You didn't ask for it, but free advice: Skip VB6 and go for a .net - language.
I'd say C#, but VB.net is equally capable. I just don't like the syntax, and getting used to a C-style syntax will make it much easier to learn java, C or C++ later on.

 

[mikeblas]

x86 Assembly (for low level kernel stuff and device drivers)
ANSI C (again, for the low-level stuff)
C++ (general Windows API stuff like MFC, DirectX, etc)
XML (windows uses XML a lot for controlling display for a lot of COM apps)
HTML (see XML)

You'll find that C++ accounts for the largest share of code in the Windows XP code base; 98% or so of what you enumerated here. The bulk of device driver code is written in C, relying on assembler for performance or control. Most HALs are completely in assembler.

There's plenty of HTML for help files, but XML and HTML aren't used much in Windows for screen definition. Since it's Windows, most everything uses native *.RC files. COM doesn't offer a UI resource language. Some newer MSFT applications do use HTML for their dialogs; they stick out like a sore thumb.

There ends up being a non-trivial amount of code for surprising things. *.MSI files, for example, for setup scripting.

 

[legendz411]

You didn't ask for it, but free advice: Skip VB6 and go for a .net - language.
I'd say C#, but VB.net is equally capable. I just don't like the syntax, and getting used to a C-style syntax will make it much easier to learn java, C or C++ later on.

Meh. I started with VB6 and it helped me learn to think in ways that I wouldnt before.

I want to learn something else now. =D

Prolly Python or Ruby

 

[ameoba]

Meh. I started with VB6 and it helped me learn to think in ways that I wouldnt before

I learned to program using C=64 Basic & MSFT Pascal on a MSFT Xenix box. I learned a whole lot, but I can't fathom suggesting that anyone do the same today. VB6 is a dead horse - the only value in learning or knowing it is if you want to support old code. Putting aside all my biases against VB, picking up VB6, given all the available languages & development environments/platforms would still be ridiculous.

 

[inotocracy]

Assembly, C and C++ is the majority.

 

[maxedoutcc]

lol

lol x2

 

[Dyslexic_Dog]

I just wanted something like this...



Thanks for all the input though. Holy shit, becareful of what you ask for.

And i'm having trouble learning visual basic 6.

When learning your first programming language, focus on the logic involved in creating the programs, try not to get stuck on the syntax of the code. You might want to try a scripting language to start with maybe something like batch would be a good place to start. Learning anything will be easier if it's in wide use and has a lot of tutorials available on the net. Most of all if you want to program you have to keep reading and keep trying things out. When you are reading a book you should be playing around with the ideas that are given to you. Often I will write simple lines of code in my head based on what I'm reading, while I'm reading it.