ESP8266 I/O handling question

I am unsure about the sequence of commands to control a GPIO pin on the ESP8266.
If I set the pin (which has an external pull-up of 1K) to be INPUT_PULLUP then I expect the physical output level to be high.
Now if I then write a zero to the pin I expect it to still be high since it is defined as output.
But what happens if I then redefine the pin mode to be OUTPUT?
Will the pin immediately drop to zero or is the value previously written lost so I must write it again?
I.e. is the output register active and can be written to even if the pin mode is input?

pinMode(5, INPUT_PULLUP);  //Pin pulled high by resistor
digitalWrite(5, LOW);  //Pin still pulled high
pinMode(5, OUTPUT);  //Is the pin now switching to low?
delay (10); //Create a 10 ms low pulse
pinMode(5, INPUT_PULLUP);  //Pin pulled high by resistor

The reason I ask is that I have used this system for bit-banging I2C lines on a Microchip PIC processor successfully in the past. This way I need only set up the port as input and write zero to it to prepare for data transmission.
Then I can switch between OUTPUT (when sending a 0) and INPUT_PULLUP to send a 1.
The PIC processor has an output latch register that holds the output bit (as zero) but the output is only presenting this when I switch the pin direction to output.
I don't know if the same holds true for the ESP8266 processor...

digitalWrite(5,LOW) will disable the internal pull up resistor.

This does not matter. I don't need the internal pull-up so I could set the mode to straight INPUT instead.
What I really want to know is if a write of a value to a pin that is set to INPUT mode will be latched internally and at a later time when the pin is set to OUTPUT mode it appears on the physical pin?

I.e. is the written data preserved until such time as the pin mode reverses to OUTPUT?

well either way it is, or switching it to output switches it to it's default 'low' state. but can't you just test it by putting some delays and test with a multimeter (or a led..)

My system is up in the attic only accessible from the outside through a small hatch 4 m above ground and it is snowing...
I will have to bring it down once I have figured out the way I have to reconnect it, but until then I have to keep it running to collect data....

I thought that this would be a "Yes there are latches behind the output pins" or "No, there are no latches that stay programmed across mode changes" kind of reply by people here who have done similar things before.

I know a lot more about the PIC24 range of micro-controllers and how they work internally than I do about the ESP8266.

So I guess I have to get another ESP system and breadboard a test circuit to find out...

well i have an ESP-01 at hand sitting on something that has a led connected to pin 2 (active-low so in a way with external pullup) and i can confirm that it does go low when set to output and back high when set to pullup.

const int pin=2;

void setup() {
  Serial.begin(9600);
  delay(1000);
  Serial.println("setting Pullup");
  pinMode(pin, INPUT_PULLUP);  //Pin pulled high by resistor
  delay(1000);
  Serial.println("setting pin low");
  digitalWrite(pin, LOW);  //Pin still pulled high
  delay(1000);
  Serial.println("setting pin to output");
  pinMode(pin, OUTPUT);  //Is the pin now switching to low?
  delay (1000); 
  pinMode(pin, INPUT_PULLUP);  //Pin pulled high by resistor
  Serial.println("setting Pullup");
  delay(5000);
}

void loop() {

}

this is the sketch i ran. But after i ran that same sketch without the digitalWrite(pin,LOW); the pin still went LOW, it's default setting i suppose..

BosseB:
The reason I ask is that I have used this system for bit-banging I2C lines

The Arduino ESP8266 Core already includes a Wire.h library that bit-bangs I2C. You don't need to reinvent the wheel.

Deva_Rishi:
. But after i ran that same sketch without the digitalWrite(pin,LOW); the pin still went LOW, it's default setting i suppose..

and when i set it to digitalWrite(pin,HIGH); it didn't so, well it does go LOW. unless you tell it otherwise, glad that's cleared up.

I have verified that my code works as I intended it to for reading DHT temp/humid sensors at least.
I am not going to do I2C for a while yet.