Visual Basic

Private Sub Form_Load()
        MsgBox "Hello world!"
End Sub

마이크로소프트 사에서 쉽고 간편하게 Windows 프로그램을 만들 수 있게 출시한 BASIC 프로그래밍 툴.

비주얼 스튜디오에 종속되어 있으며, 인터페이스가 매우 쉽고 간편하여 짧은 시간 안에 Windows 기반 프로그램을 만들 수 있다. 그리고 API, MFC처럼 코드로만 프로그래밍을 하는 것이 아니라, 도구 상자에 있는 여러 오브젝트들을 드래그 앤 드롭으로 프로젝트 내에 추가할 수 있다. 예를 들어서 API에서 커맨드 하나를 만드려면 긴 코드를 작성해야 하는데, 비주얼 베이직에서는 오브젝트를 끌어다 놓는 것 하나만으로 커맨드 하나를 만들 수 있다. 이처럼 쉬운 제작 환경 덕분에 다른 것들보다 훨씬 빨리 프로그램을 만들 수 있다.

후속작은 Visual Basic .NET(VB.NET)이다.

1991년 5월에 발표되었다. 사진은 윈도우용 비주얼 베이직 1.0이며[2], DOS용으로도 출시되었다. 이래 봬도 프로그램 제작 툴이다.

윈도우용 파일. 윈도우 3.x대 프로그램은 16비트 어플리케이션인데 64비트 윈도우는 16비트 애플리케이션 지원 기능이 없으므로(AMD64 참고) 네이티브 실행이 불가능하다. 따라서 32비트 OS(Windows XP 등)로 실행하거나 가상머신으로 MS-DOS를 설치하고 실행하면 된다. 아니면 도스용 비주얼 베이직을 구해서 도스박스로 구동시켜도 된다.

각각 사용 가능 윈도우 버전이 올라간다. 국내에서는 5.0 때부터 정보올림피아드 과제 수행을 하기도 하였다. 5.0부터는 16비트 윈도우에서 사용이 불가능하다.

1998년에 출시되었고, 2005년에 지원 중단된 Visual Basic의 마지막 버전. 아직도 점유율 20위 안에 드는 언어다. # 이 버전을 끝으로 .NET Framework 기반의 Visual Basic .NET으로 넘어간다.

MS 오피스에서 사용되는 VBA의 기반이 되는 버전이기도 하다.

아직도 사용자가 많은 이유는 VB 6.0 다음 버전이 VB.NET이기 때문이다. 일단 호환도 안 될 뿐더러 VB 6.0은 절차 지향, VB.NET은 객체 지향 언어이기 때문에 아예 코딩하는 방식을 바꿔야 한다. 그래서 아직 VB 6.0을 고수하고 있는 사용자도 있다.

MS는 VB 6.0을 쓰지 말고 VB.NET을 써 달라고 부탁했지만 현실적으로 힘들다. 이미 VB의 압도적인 장점인 쉬운 GUI 구축과 VS 6.0의 장점인 가벼움이라는 무기로 수많은 프로그램들은 이걸로 만들어졌기 때문에 유지 보수에 VB.NET의 사용 가치가 없었다. 그마저도 VB 6.0 당시는 영문버전으로 하면 .exe 파일만으로도 구동이 가능했으나[5], .NET 프레임워크가 하루가 다르게 신버전이 나와, 프로그램 배포 무게가 점점 무거워졌다.

결과적으로 몇천줄 몇만줄 되는 코드를 함수, 변수 수정 같은 방식이 아니라 코딩 패러다임에 맞게 모두 갈아 엎기보다는 그냥 옛날 버전으로 프로그래밍 하는 게 낫다. Visual C++ 6.0도 비슷한 신세를 겪었지만 그래도 이쪽은 최신 버전의 비주얼 C++를 통해 컴파일을 시도라도 해볼 수 있었던 반면에, 상용 수준으로 개발된 VB 6.0 프로젝트를 닷넷으로 변환할 때에는 그야말로 건질 수 있는 게 없다시피 하므로 그냥 포기하고 새로 개발하는 편이 나을 정도. 그럼 그냥 새로 개발하면 되지 않느냐 하겠지만 "그랬다가 되던 기능 안되면 니가 책임질래?" 또는 "저런 작업에 사용할 인력이나 예산 따윈 없음" 한마디면 회의실에는 적막만 감돈다. 정말 짜증난다면 개인 시간을 사용해서라도 다른 기술을 쓰되 동일한 기능을 가진 모듈을 개발해봐도 좋겠지만, 그런 노력에 환호하던 사람들도 기능이나 호환성 문제 발생시 본인에게 다 전가하려 할 것이다(...). 결국 그냥 예전에 되던 걸 그대로 다시 쓰는 게 모두가 원하는 일이니 오늘도 누군가는 최신 윈도10 PC에 VB 6.0을 설치할 수밖에 없는 것이다. 웬만한 검색엔진에 Visual Basic 6이나 Visual Studio 6까지만 쳐도 윈도10에서 설치하는 방법이 자동완성(...)으로 뜨는 것은 이런 이유.

이 때문에 매년 VB 6.0을 지원해 달라고 프로그래머들은 MS에 진정서를 넣지만, MS는 여전히 VB.NET을 쓰라고 한다. 점점 OS 차원에서도 VB의 지원을 줄이고 있지만 그럼에도 불구하고 아래와 같은 편법을 써서 계속 사용하는 사람들이 있다. 쓰레드는 Windows API로 쓰면 가능하며 파일 삭제, 등의 입출력도 Windows API로 쓰면 한방에 해결된다. MS는 이미 C와 같은 점유율도 높은 언어조차 제대로 지원하지 않고 있기에, 정식 지원에 대한 전망은 비관적이다. VB로 만들어진 프로그램이나 모듈을 사용할 때 나타날 수 있는 보안 취약점 정도나 겨우 수정되는 수준이고 이마저도 언제 중단될지 모르지만, 아마 취약점 해결마저 중단된다 해도 인터넷 연결을 하지 않는 장비 등에서 끈질기게 명맥을 유지할 것이다. 앞서 설명한 대로 그것밖에 답이 없으니까.

만약 VB 6.0을 Windows XP가 아닌 Windows 7에서 사용하려고 하면 가능하면 IE 10 이상으로 업그레이드 하지 말자. IE 9까지는 괜찮지만 IE 10.0 이상으로 업그레이드 하면 기존 IE 8/9 기반 컨트롤(*.ocx) 중 일부를 사용할 수 없게 된다. 따라서 IE 9를 지원하지 않는 Windows 8 이상의 운영체제에서는 개발을 권장하지 않고 Windows 10 64비트에서는 아예 동작되지 않는 것으로 알려져 있다. (호환성 설정을 하면 구동은 가능하다.)[6]

백신이 컴파일 된 실행파일을 바이러스로 인식하는 경우도 있다. 대표적인 예로 알약이 있는데, 모처럼 수백/수천대에 배포했던 프로그램을 바이러스라며 한방에 다 삭제 시켜버리기도 했다. 뒤늦게 알약에 항의하면 바이러스항목에서 빼주나, 프로그램을 업데이트하면 다른 프로그램으로 인식해 다시 바이러스로 등록하는 웃지 못할 영업방해도 많았다. 알약을 안 쓰면 된다.

VB 6.0에서는 VC++ 6.0과 다르게 마우스 휠이 제대로 동작하지 않는 버그가 있다. #1 #2 IntelliPoint 소프트웨어가 버전 4.9 이상에서는 동작하지 않으므로 IntelliPoint 소프트웨어 버전 4.12 이전 드라이버를 사용하는 방법도 있다. 아니면 추가 기능으로 패치하는 방법이 있다.

Visual Studio .NET(2002)부터 VB는 사라지고 VB.NET(Visual Basic .NET)으로 대체된다.

Visual Studio 6.0에 이르기까지 윈도우와 다르게 설치 시리얼키가 허술하게 관리되었다. 모든 시리얼키 입력창을 1로만 입력해도 통과되는 웃지 못할 일도 있었다. 때문에 정식 라이센스를 보유하고 있는 학원이나 업체조차 귀찮아서 111-1111111로 입력하는 경우도 있었다. 당시 구매가 백만원이 넘어가는 프로그램에서 이를 보완하기 위한 서비스팩 1부터 서비스팩 7에 이를때까지 차단하거나 고쳐지지 않은 것을 보면 윈도우용 프로그램이 많이 생산되길 바랬거나 라이센스 관리 자체에 관심이 없었던 것으로 보인다. 일단 플랫폼을 장악하는게 중요하거든 참고로 이는 Windows 95용 Microsoft Plus!에서도 먹히는 수법이다.